Exceptions or Error codes?
Wednesday, 5. September 2007, 11:07:03
Exceptions and error codes.
Exceptions are the OOP way of doing things: You throw a new exception, where the exception is a new instance of some exception class.
Error codes are "oldschool": They are just values returned from the function, but with special meanings.
But which one is a better choice and why?
Advantages of Exceptions
Exceptions have certain problems - Joel Spolsky puts it quite well in his blog, amongst other things -
The reasoning is that I consider exceptions to be no better than "goto's"
I somewhat agree with this, but I think exceptions do have a few advantages over error codes too.
Exceptions are more literal than error codes. If your application crashes and bursts into flames with "function returned -2", you won't know what went wrong, but if your application crashes and bursts into flames with "uncaught exception FileIOException", you immediately can see that there's a problem in File I/O.
That is just one of the advantages. With exceptions, you can have more information about what went wrong. Since the exception is a class, you can populate it with whatever data you want before you throw it. If you are returning error values, you can only return the error value and that's it. Languages which let you easily return multiple values are, of course, an exception to this, but I can't think of any much used language that supports this.
Exceptions also have the advantage of halting the execution of the whole application if they are left uncaught. If you fail to parse a returned error code, in the worst case your application continues running but in a half-broken state and causes more problems, perhaps even corrupting data.
Catching properly
There is also a incorrect and a correct way to catch exceptions.
Most languages provide a try-catch block for doing this and a bunch of different classes derived from a base Exception class.
What many people do, is that they catch the base Exception class and not one of the more specialized Exceptions.
This causes a few problems: If you just have code to fix, say, a broken DB connection in your catch block and the exception thrown doesn't even have anything to do with the DB, your code might be doing completely wrong things and you don't even know about it.
If you had caught the more specific DatabaseException (or whatever it might be called) instead of the generic Exception, other exceptions would stay uncaught and you'd know about them.
So what about Error Codes?
The obvious advantage is that they are much simpler and they won't halt the whole application if not "caught". While this may cause problems as mentioned above, it may also be an advantage depending on the situation.
Error codes are also easy to use in if-clauses:
if(myFunction() == ERROR_FOOBAR) { /* problems */ }
While not much different from a try-catch block, a "traditional" approach like this may be better suited for some people.
Returning an error code is also faster than throwing an exception. Throwing an exception has a small overhead.
So which one wins?
I personally prefer exceptions, but like the name says, they are exceptions - Only use them in exceptional conditions. Don't use them for controlling program flow, like mentioned, they do have a small overhead and therefore can slow your application down if a lot of exception throwing occurs.
Depending on the size of the project, exceptions may be a better choice. I think it is easier to have and handle many kinds of exceptions than many kinds of error codes. In smaller projects it probably doesn't matter as much.








Anonymous # 6. September 2007, 12:18
That Joel on Software post is so old!
I've used Java much, so exceptions are more natural for me. I hadn't ever thought about them as gotos, though.
zomg # 6. September 2007, 12:23