Lazycoder

Exception handling.

Do we sometimes have too much “faith” in the .NET Framework?

Fabrice had a discussion in the comments on a post he made about correct exception handling. Lamont points out the lack of exception handling in some code he’s seen lately. The question I have is: What do you do if you catch a SQL exception when you are opening a SQLConnection? If you can’t even connect to the database you’re boned right? Best thing you can do, unless you want to serialize the data to the users local machine or web server depending on what kind of an application you are writing, is log the error for your benefit and present a friendly message to the user. If you get an IOException what can you do other than report it.

In the same comment thread, Larry Osterman wonders what you do if your SqlConnection constructor throws and you don’t have a try-catch around it. My thinking is if a constructor throws I’m extra spicy boned. It’d have to be a runtime error and it’d have to do with the arguments I’m passing in. I can’t really write exception code that will re-cast or re-form my arguments into ones that the constructor will accept (well you CAN using the code emitter in .NET and some nifty in-memory compilation but that’s a little beyond the scope of this post).

My point is that exceptions are just that, exceptional. I usually have a global exception handler that logs the exceptions and presents the pretty error message to the EU. i’ve seen the horror of checked exceptions in Java. I’m glad I don’t have to swallow exceptions or re-throw them because I can’t do anything about them.