Which Error Handling Model Is More Robust?

Question

I'm kind of torn between these two error-handling models:

1. Create a boolean Error and a string ErrorMessage property for your object. Catch all exceptions internally in the object's methods and pass the messages along using conditional logic from the caller, ie:

   Dim o As New MyObject
   o.SomeMethod()
   If Not o.Error Then
       'Do stuff'
   Else
       Dim msg As String = o.ErrorMessage
       'do something with message'
   End If
   

2. Throw exceptions in your object and handle them on the outside with Try Catch logic:

   Dim o As New MyObject
   Try
      o.SomeMethod()      
      'Do stuff'
   Catch ex As Exception
       Dim msg As String = ex.ErrorMessage
       'do something with message'
   End Try
   

To me, it seems like the same amount of code either way, except that you have property code for the Error and ErrorMessage properties. However, you also can tell when an error occurs without having to check for exceptions. Which pattern should I go with?

Answer 1

The biggest issue I have with the first one is that it's passive, easily overlooked and not very standardized. How will a programmer know to check that property? Or which properties / methods can possible set an error? Or which property / method access caused the error to be set?

For example. In your first sample code if o.Error is True, it's unclear whether the initialization of the object or the call to SomeMethod caused the flag to be set.

The exception model is an unignorable way of telling your users that an error occurred. It cannot be avoided without explicit code to handle the situation.

Answer 2

I have decided to go with throwing exceptions instead of using error/return codes. I just recently looked really hard into this.

The #1 reason to throw exceptions is there is a possibility you can forget to check the error code. If you don't check it, then you will continue working while the error exists. With exceptions though, if you forget to handle them, then the exception will raise to the top and stop all processing. It is better for this to happen than to continue after unknown errors have occurred.

For more info check out the Exception chapter in Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, Second Edition by Addison-Wesley.

Joel Spolsky actually prefers error/return codes over exceptions but a lot of people disagree with him. Joel's post in favor of return codes can be found here. Check out this blog post and all of the comments with some good discussion regarding this subject.

Answer 3

Prefer #2. For details, see this excerpt on Exception Throwing from the development of Microsoft's excellent Framework Design Guidelines, as Dennis mentioned. Note especially the section on Exceptions and Performance.

Short version:

Do not return error codes.

Do report execution failures by throwing exceptions.

Do not use exceptions for normal flow of control.

I highly recommend reading the book for a full discussion, complete with commentary from a number of the Microsoft luminaries.

Answer 4

Exceptions should be used when something exceptional has happened.

e.g. you are passed a null (nothing) object when you expect one.

Uncle Bob recommends Exceptions over Error codes in his book Clean code.

He says

The problem with these [error codes] approaches is that they clutter the caller. The caller must check for errors immediately after the call. Unfortunately it's easy to forget. For this reason it is better to throw an exception when you encounter an error. The calling code is cleaner. Its logic is not obscured by error handling.

Answer 5

They are both accepted forms of error handling, however the preferred choice for .NET languages is to use exceptions.

There are a few problems with using return codes (either numeric or boolean), the two biggest being:

• Easily overlooked/ignored by programmers.
• Can't be used in all situations. What happens if your constructor fails? It's not possible for you to return a value explicitly from a constructor.

For these reasons alone, you should use exceptions. Exceptions provide a clean, standardized way to indicate and any failure no matter where it arises.

You will also end up with less code overall as you should only catch exceptions when and where you can safely and appropriately handle that exception.

Answer 6

I recommend using both.

Why?

"Use the right tool for the job"

The "problem" with return codes is that people often forget to handle them. However, exceptions don't solve this problem! People still don't handle exceptions (they don't realise a certain exception needs to be handled, they assume somebody up the stack will handle it, or they use a catch() and squash all errors).

While an unhandled return code might mean the code is in an unstable state, an unhandled exception often guarantees that the program will crash. Is this better?

While a return code is easily identifiable when writing code, it is often impossible (or just tediously time-consuming) to determine what exceptions might be thrown by a method you are calling. This typically results in a lot of very poor exception handling.

Exceptions are supposed to be used for "errors". Therein lies the difficulty. If a file is not found when you try to open it, is that an "error", or an "expected situation"? Only the caller knows. Using exceptions everywhere essentially elevates every piece of status information into an error.

Ultimately, error handling is something a programmer has to work at. This problem exists in both return codes and exceptions.

Thus, I use return codes for passing status information (including "warnings"), and exceptions for "serious errors". (and yes, sometimes it's hard to judge which category something falls under)

Example case from .net:

Int32.Parse throws exceptions (even though none of its exceptions are errors - it is up to the caller to verify the results and decide for themselves if the result is valid). And it's simply a pain (and a performance hit) to have to enclose every call to it in a try/catch. And if you forget to use a try/catch, a simple blank text entry field can crash your program.

Thus, Int32.TryParse() was born. This does the same thing, but returns an error code instead of an exception, so that you can simply ignore errors (accepting a default value of 0 for any illegal inputs). In many real life situations this is much cleaner, faster, easier and safer to use than Int32.Parse().

"TryParse" uses a naming convention to make it clear to the caller that errors might occur, that should be correctly handled. Another approach (to force programmers to handle errors better) is to make the return code into an out or ref parameter, so that the caller is explicitly made aware of the need to handle returned errors.