Exceptions or Error Codes (will it ever end?)

Joined in on a discussion today about should services raise exceptions or return error codes. Ron Jacobs listed quoted the following…

According to the .NET Framework Class Library Design Guidelines

Exceptions are the
standard mechanism for reporting errors. Applications and libraries
should not use return codes to communicate errors. The use of exceptions
adds to a consistent framework design and allows error reporting from
members, such as constructors,that cannot have a return type.
Exceptions also allow programs to handle the error or terminate as
appropriate. The default behaviour is to terminate an application if it
does not handle a thrown exception.”Sure enough you don’t see error codes within framework, however I’m not 100% convinced. The first problem I have with exceptions is one of performance. The stack walking involved in processing an exception should not be ignored. However, I’m convinced that I’ve read that the exception handling mechanism is going to change to reduce the performance impact…can I find any evidence of it? No, maybe I dreamt it. So I’m going to conveniently ignore performance for now and move onto my second gripe with exceptions, that of handling exceptions. To illustrate the point let me introduce the following example, you need to write a business component that will transfer funds from one account to another. The component contains a number of rules;
1. Does the client have access to account A?
2. Does the client have access to account B?
3. Are there enough funds in account A?
4. Is account A open?

The Microsoft recommended route seems to be to create an exception for every rules. So you’d end up with something like;
1. AccountFailedAccessException(arg)
3. AccountInsufficientFundsException
4. AccountClosedException

To catch these exceptions you need to write a specific catch statement for every type of exception. This is fine if you actually want to respond to each exception in a specific way but lets say the client is only interested in, "did it fail an access check" or "some other non access problem". This is a depressingly annoying to implement since you have to catch each exception and repeat handling code, e.g.
If this was an old style error code then a switch statement would easily consume similar codes…
case: AccountFailedAccess
case: AccountInsufficientFundsException
case: etc

Now I’ve now become convinced that exceptions are the way to go (for none performance critical) errors. The obvious solution to the above problem is to create a hierarchy of exceptions…

Therefore if you’re only interested in something going wrong with the Account component you’d catch nothing but the root exception of AccoundException. If you want any other exception apart from Access then you’d catch AccountNonAccessException, etc. Although this sounds good I do concede that it is still a pain to code all those exceptions.

What happens if performance is still and issue? If there is no getting away from performance then the answer is to return a state structure/class or an enum. However, the big problem with this approach is the client isn’t required to consume return code. The great thing about an exception is its in the hands of the OS, if you choose to ignore the exception then the program counter will be whipped away from you. So isn’t an easy choice for the performance freaks but I feel the tide of change is such that if you do go the error code route then fewer clients will like you for it, and in the world of SOA it is becoming harder to ignore that unknown client. I just hope I didn’t dream about the change to SEH (Structure Exception Handling) and that a new performance oriented version is around the corner.

This entry was posted in Computers and Internet. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s