Geeks With Blogs
The Stumblings of an IT Manager ...2 days before we go live and you want WHAT....?

Was working on a windows form app (something I haven't done in a while), adding threading and logging so that it would work a little more smoothly and have a record of who did what.  I was just about at the point where I was going to check it into source control when I noticed that the Output window was showing "A first chance exception of type 'System.InvalidCastException' occurred in mscorlib.dll", so I googled it.  In reading some threads about the error, I came across the following comment and it got me thinking:

"In addition, while they should be avoided if possible, exceptions are a quite legitimate part of program execution. It's their going unhandled that is a real issue, because that means crashy, crashy."

How do you normally use exception handling?  I feel that exceptions are intended to handle errors in code (in my experience generally related to bad data making its way into the system).  Now don't get me wrong, I understand that exceptions happen and should be dealt with, but I feel that they are a "last resort" to keep a program from crashing, but should never be a way to pass data or continue logical processing that could be handled in standard code flow. I mention this, because I have seen it done.

What do you think?

Posted on Thursday, May 20, 2010 11:31 AM | Back to top

Comments on this post: Thoughts on exception handling.

# re: Thoughts on exception handling.
Requesting Gravatar...
I find it helpful to I think of errors as "unexpected Conditions". It is not a coding bug if your database server is down, and swallowing such an error in the DAL and returning null is asking for trouble. I feel an component should throw an exception when an condition occurs that is not expected, or not within the scope of the Component's responsibilities. By throwing exceptions, you tell the calling component, "Hey there is a problem, but it's not MY problem, you deal with it!"

Example, If I have a bank application, and I have a component that transfers money from one account to another, The component should deal with performing an accurate transaction. It may not want to handle one or both Accounts not existing. If it runs into this issue, and throws an AccountNotFoundException, the calling code can do what it needs to deal with the situation. (show the exception to the user)

Exceptions can be a way of defining responsibility boundaries of a components, making them less complicated by letting them Assert a condition is a requirements (Both Accounts must Exist) and clearly communicating the problem back to the calling code.

In a Banking applications there would be many components doing many different tasks with accounts. If all these components tried to handle An account that did not exist condition, your code would become unruly. If, instead, 1 component were expected to handle this, you end up with less code.
Left by Brian on May 20, 2010 4:19 PM

# re: Thoughts on exception handling.
Requesting Gravatar...
That last example is what I am referring to as correct. You are specifying that the "account not existing" condition should be handled in another area, and I would guess, checking that condition before continuing.

Specifically, when designing the components, you make assumptions (like the account exists), and code from there. Not to say you abandon error checking within individual modules/components, but when your Catch statements become like a case statement, I think you have done something wrong.

The situation that I have run into recently would be more akin to an account having insufficient funds. When you call your WithdrawFunds method, I would expect you have already checked the account for sufficient funds, not handling that condition from a:
Catch (Exception NegativeFundsCannotExist)
then throwing a specific error message. I understand the need for this type of specific error handling, but I think that it should be more the exception than the rule (pun intended).

But again, thats just me, and I am always open to suggestions.
Left by AndyScott on May 20, 2010 4:37 PM

Your comment:
 (will show your gravatar)

Copyright © AndyScott | Powered by: