Programming with Exceptions
I’ve been reading a lot of blogs by programmers lately who have lukewarm feelings about exceptions. I don’t understand this. I have always loved exceptions because I don’t have do all of that error code checking. Not only is it a lot of work, it makes code hard to read, ugly and you have to think about what to do in the case of each error. Most of the time I’m too lazy for this and therefore don’t have appropriate error handling in my application.
Exceptions solve all these problems. Programming with error codes doesn’t make much sense in .net because exceptions can be raised anytime, and therefore your code needs to be exception-safe anyway. The error codes don’t buy you anything. I’m trying to think about why I don’t have a problem with exceptions. I think there are three types of exceptions that you should concern yourself with as developer.
1) Exceptions that can come up under normal usage of the software. (For ex, DNS related exceptions) If these exceptions come up, its probably not your fault, but it is your problem, So you handle them explicitly.
2) Exceptions that shouldn’t come up, but if they do, they shouldn’t crash your program. Stored procedure errors fall into this category. You don’t want your application server crashing because a bad table name in someones sql code. Also, you can’t preconceive a solution to everyone of these errors that might happen(How will you handle OutOfMemoryException?). Therefore, you have to structure your program so that these types of errors can be caught and logged, while the program marches on.
3) Exceptions that have to crash your program. Sooner or later, an exception will come up in such a way that your program cannot recover. It happens to the best of us. The only thing to do is exit gracefully. The important thing is not to show your user the default .net exception dialog. Therefore, use the AppDomain.UnHandled exception event to notify the user of the problem before exiting. If your application is a Windows Service, make sure you don’t show a dialog to the user, or else it may have a hard time restarting.
Most people’s issues with exceptions stem from handling type 2 exceptions I think. The program is not structured in a way that allows the bulk of miscellaneous exceptions to be caught. Most of the programs I write I have centralized management code that is responsible for invoking almost of the application code. Therefore if the management code is able to gracefully handle any miscellaneous exceptions from the application, you don’t have an issue with exceptions. In a web application you can do this with the FrontController pattern. Create a single page with your management code, and use dynamically loaded Controls on it rather than having different pages for each type of request.
In a Windows Forms gui, there is an event on the Thread class you can use to handle any ui exceptions(Can’t remember the name now). In a asynchronous application, I strongly recommend the MetaTransform archictecture I mentioned previously. You can put exception handling code around the call to ProvideService(), as well as the call to the result delegate. If you do that your application will be virtually uncrashable, assuming your startup code is solid.