A developer at work posted a couple interesting threads on error codes vs. exception handling today.
Here is my take:
Handling errors is hard and takes discipline
matter what your approach to error handling is it is probably one of
the most difficult things to deal with when writing code (at least it
is for me). There are going to be some situations that are so serious
that there is no point in continuing the application so shutting down
is the best solution (network failure in a client /server application).
It is the errors that aren’t that serious or can possibly be recovered
from that are more challenging to handle. I believe handling these
situations well are one of the differences between an application that
is user friendly and one that is not. Based on past experience it is
these kinds of exceptions I see that are left with “todo” comments or
the exception is logged and the application continues as if nothing
What’s wrong with error codes?
biggest problem with error codes is checking them. I worked on a
project that it was part of the coding standards that every method had
a Boolean return value. Every time a method was called the return value
had to be checked. I think this was a bad standard but that is another
story. What ended up happening is people stopped checking the return
values. Why this happened I don’t know for sure but it was probably
related to time pressures and handling an error condition properly took
more thought and time.
What’s wrong with exception handling?
biggest problem I have with exception handling in .NET is if the
developer doesn’t know what exceptions are being thrown by a method
what typically happens is System.Exception is caught or exceptions
aren’t caught at all. Of course catching no exception at all isn’t a
good idea but if System.Exception is being caught the user probably
isn’t getting a specific error message that might help them resolve
their current issue (aka not so user friendly).
not trying to start a language debate but one thing I really wished
that Microsoft had copied from Java was enforcing catching of
exceptions. Using Java with a good IDE the developer doesn’t have to
worry about looking up the specific exception that a method might
throw. Or you can use notepad and the command line and get good result
as well. This doesn’t make it is any easier to deal with an exception
once you have it but I think it is a step in the right direction.
public class test
public void writeList()
PrintWriter out = new PrintWriter(new FileWriter(“OutFile.txt”));
Command line output
test.java:7: unreported exception java.io.IOException; must be caught or declared to be thrown
In my opinion there are issues with both approaches, if there wasn’t it wouldn’t be debated or would it?
If I were to pick one side of the fence I would go with exception
handling. Dealing with and exception class opposed to an error code
constant makes more sense to me. I think the industry has moved (if not
is moving) toward exception handling so instead of debating if error
codes are better we’d be better trying to figure out how to make
exception handling better.