Error Handling with Exceptions

Why does .NET take such a Draconian stance on error handling? With C++, several methods were available for handling errors, exceptions being among them. VB had an error-handling scheme that was remarkably similar to exceptions. The list goes on; each language had its own method of dealing with errors. Indeed, that was the problem. Each language had one or more ways of handling errors. One of the goals of the .NET platform was to create a unified environment where all languages were “equal.” For a language to interoperate seamlessly with another language, the error-handling schemes must be the same. If the error handling tried to be all things to all languages, then every time a new language or even a new error-handling scheme was introduced, the CLR and .NET Framework would need to be redone. One scheme had to be decided on, and using exceptions seemed to be the best choice for two reasons:

• Exceptions are hard to ignore.

• Exceptions allow a programmer to decide easily the proper context in which to handle the error.

Difficulty in Avoiding Exceptions

A compelling reason to adopt exceptions as a means to handle errors is that exceptions are harder to ignore than the traditional error code return. The designer of an API must return an error code hoping that the user of the API will read the error code and do the right thing. If the user is lazy or under a schedule constraint for reading the documentation, he might just ignore the values returned. Depending on the API, ignoring the return code could leave some latent bug in the code waiting to become more apparent. Usually by the time the bug is noticed, the cause of the error has long since been forgotten. Finding the source of the problem is the key to solving it.

If the programmer is not diligent about checking all of the error codes, errors could creep in. These kinds of errors are time-consuming to fix and make the code that much harder to maintain. Of course, exceptions can also be ignored, but if they are ignored and an unhandled exception handler is not present, the program crashes, giving a visible sign that something is wrong. A programmer can also get around handling the error by “handling” the exception in a generic sense and doing nothing. However, exceptions make handling errors easier because the code for handling the error is isolated and apart from the error-free code. In addition, testing for return codes for each function call can add extra lines of code, especially if the types of errors are the same among a group of function calls.

Proper Context for Handling Errors

Often when an error occurs, the code that is to handle the error does not have enough information or background to know how to best handle the error. For example, if a file is not found, one possible way to handle that error is to create it.