Exception Handling (Windows Applications)

[clamum]

I have been wondering for some time about how others handle exceptions. I am concerned primarily with Windows applications, specifically .NET, but feel free to add your expertise in other areas if it's relevant (most of which it should be; exception handling in Java would be similar I'd think). I did some searching here and a bit on the Internet and found Vexing Exceptions which was alright I guess.

But I'm interested in what you guys do and think.

Most of the newer applications at my job are structured like this:

private void DoSomething(string param1)
{
     try
     {
          // do stuff
     }
     catch (Exception ex) { }
}

Every method is like that, big or small. Part of the reason is due to a practice begun long ago that was because, from what I gather, when an exception occurred they were having issues with not having the full, correct stack trace. But even ignoring that stack trace thing, we still put the entire method in a try/catch block.

Now I was always of the impression that you should only put a try/catch block around code that might blow up, such as reading/writing files, opening or executing databases and queries, and so on.

One more thing that is particular to where I currently work. The applications we run are part of a system that runs every two hours (to be simple about it). Every two hours, this big process starts and these applications get triggered to run sooner or later. Any exception in them will display an error MessageBox on the screen which a monitoring app sees. The monitoring app takes a screenshot and sends out an email with the image attached and the exception message, and someone then fixes the issue. We deal with tons of customer/client data, and it might be just due to that in some way (it's usually not an *app* bug per-se, but due to some other data or database state).

Anyway, I was wondering what other Windows app developers do about exceptions. I have a feeling putting every method in a try/catch block is crappy design, but it works for us. We get the stack trace, the error gets handled (the app is frozen with the MessageBox up of course until we resolve it). I know it's probably not the "proper" way to write an app, but if it works for us, so what? One thing that is a drawback of this is that when an exception does occur and we gotta find the exact line of code that cause it, it can be a little tricky because we don't have a line number to go to and have to try and determine exactly which line it was.

So... lemme hear your exception handling wisdom!

 

[Ken g6]

Is there really nothing in your catch blocks? Putting try/catch around everything is one thing; not even logging the exceptions is another. http://mike.pirnat.com/2009/05/09/the-diaper-pattern-stinks/

 

[Cogman]

Generally, catch an exception if you will do something with it. Don't catch it if you will do nothing with it.

Exceptions should be used when something exceptional happens. They should not be used when nothing exceptional happens (In other words, don't use exceptions for control flow).

Every application/thread should have some common exception handling mechanism that logs away uncaught exceptions for you to digest later.

I agree with ken. If you catch an exception you SHOULD do something with it. The only exception (tee hee) here is when an exception is being thrown too aggressively (looking at you NumberFormatException in java).

When it comes to throwing exceptions. You should throw them when errors in the code or system occur. You should not throw an exception for day to day processing. In that case you should use something like a tuple that can be easily digested and thrown away if needs be.

 

[Hmongkeysauce]

I would add that if you're just logging the exception in your catch block, then, remember to re-throw it.