Question

I recently had to develop an additional module for an existing service developed by a colleague. He had placed a try/catch block in the main working function for catching all unhadled exceptions that bubbled up to this level, logging them together with stack trace info etc:

try {     // do main work } catch(Exception ex) {     // log exception info } 

While this makes the program very stable (as in ‘unlikely to crash’), I hate it because when I am testing my code, I do not see the exceptions caused by it. Of course I can look at the exception log and see if there are new entries, but I very much prefer the direct feedback of getting the exception the moment it is thrown (with the cursor on the right line in the code, please).

I removed this top level try/catch at least while i was still coding and testing. But now my task is finished and I have to decide wether to put it back in for the release, or not. I think that I should do it, because it makes the service more stable, and the whole point of it is that it runs in the background without needing any supervision. On the other hand I have read that one should only call specific exceptions (as in IoException), not generically Exception.

What is your advice on this issue?

By the way, the project is written in C#, but I am also interested in answers for non .NET languages.

Answer 1

Put it back.

The exception should be only relevant while testing. Otherwise it doesn’t make sense pop it to the user.

Logging is fine.

You may additionally use the DEBUG symbol defined by Visual Studio for debug builds as a flag.

    ...     } catch( Exception e ) {  #if DEBUG           throw; #else           log as usual  #endif     } 

So next time a modification is needed the debug flag should be set to true and the exception will pop up.