How to implement top level exception handling?

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 al

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.

Answer 2

If you want to see the exception when it occurs, in Visual Studio you can go to the DEBUG menu, select EXCEPTIONS and you can tell the debugger to Break as soon as an Exception is thrown. You even get to pick what type of Exceptions. :)

Answer 3

Ideally you want to handle an exception as close to where it occured as possible but that doesn't mean a global exception handler is a bad idea. Especially for a service which must remain running at all costs. I would continue what you have been doing. Disable it while debugging but leave it in place for production.

Keep in mind it should be used as a safety net. Still try to catch all exceptions before they elevate that far.

Answer 4

In any Java application, you just about always want to define an exception handler for uncaught exceptions with something like this:

Thread.setDefaultUncaughtExceptionHandler( ... );

where the object that will catch these uncaught exceptions will at least log the failure so you have a chance to know about it. Otherwise, there is no guarantee that you'll even be notified that a Thread took an Exception -- not unless it's your main Thread.

In addition to doing this, most of my threads have a try/catch where I'll catch RunnableException (but not Error) and log it ... some Threads will die when this happens, others will log and ignore, others will display a complaint to the user and let the user decide, depending on the needs of the Application. This try/catch is at the very root of the Thread, in the Runnable.run() method or equivalent. Since the try/catch is at the root of the Thread, there's no need to sometimes disable this catch.

When I write in C#, I code similarly. But this all depends on the need of the application. Is the Exception one that will corrupt data? Well then, don't catch and ignore it. ALWAYS log it, but then Let the application die. Most Exceptions are not of this sort, however.

Answer 5

The urge to catch all exceptions and make the program 'stable' is very strong and the idea seems very enticing indeed to everyone. The problem as you point out is that this is just a ruse and the program may very well be buggy and worse, w/o indications of failures. No one monitors the logs regularly.
My advice would be to try and convince the other developer to do extensive testing and then deploy it in production w/o the outer catch.