Chapter 18: Exceptions Overview In this chapter, I’ll talk about a powerful mechanism that allows you to write more maintainable and robust code: exception handling. Here are just a few of the benefits offered by exception handling: § The ability to keep cleanup code in a localized location, and the assurance that this cleanup code will execute By moving cleanup code out of an application’s main logic to a localized location, the application is easier to write, understand, and maintain. The assurance that the cleanup code runs means that the application is more likely to remain in a consistent state. For example, files will get closed when the code writing to the file can no longer continue what it’s doing for whatever reason. § The ability to keep code that deals with exceptional situations in a central place A line of code can fail for many reasons: arithmetic overflow, stack overflow, outof-memory status, an out-of-range argument, an out-of-range index into an array, and an attempt to access a resource (such as a file) after it has been closed, to name a few. Without using exception handling, it’s very difficult, if not impossible, to write code that gracefully detects and recovers from such failures. Sprinkling the code to detect these potential failures into your application’s main logic makes the code difficult to write, understand, and maintain. In addition, having code that checks for these potential failures would be a huge performance hit on an application.
§
Using exception handling, you don’t need to write code to detect these potential failures. Instead, you can simply write your code assuming that the failures won’t occur. This certainly makes the code easier to write, understand, and maintain. In addition, the code runs fast. Then you put all your recovery code in a central location. Only if a failure occurs does the exception handling mechanism step in to execute your recovery code. The ability to locate and fix bugs in the code When a failure occurs, the common language runtime (CLR) walks up the thread’s call stack, looking for code capable of handling the exception. If no code handles the exception, you receive a notification of this “unhandled exception.” You can then easily locate the source code that issued the failure, determine why the failure happened, and modify the source code to fix the bug. This means that bugs will be detected during development and testing of an application and fixed prior to the application’s deployment. Once deployed, the application will be more robust, improving the end-user’s experience.
When used properly, exception handling is a great tool that eases the burden on software developers. However, if you use it improperly, exception handling can bring much sorrow and pain by hiding serious problems in the code or by misinforming you of the actual problem. The bulk of this chapter is dedicated to explaining how to use exception handling properly.
The Evolution of Exception Handling When designing the Win32 API and COM, Microsoft decided not to use exceptions to notify callers of problems. Instead, most Win32 functions return FALSE to indicate that something is wrong and then the caller calls GetLastError to find the violation. On the other hand, COM methods return an HRESULT. If the high bit is 1, an assumption was violated and the remaining bits represent a value to help you determine the cause of the violation. Microsoft avoided using exceptions with Win32 and COM APIs for many reasons: § Most developers are not familiar with exception handling.