Writing many try-catch-finally blocks is a typical sign of a developer who does not understand how structural exception handling works. This thing is one of the greatest inventions if software development which allowed to avoid boring and error-prone "error handling". It also allows to separate "regular" code from handling of exceptional situation. The whole idea of the technology is to write software freely, completely ignoring possibilities of such situation. When some handling is needed, it can be easily added later. This is even better.
So, don't worry, nothing is lost.
You only need one try-catch-finally block on the very top of the stack of each thread, in some cases two nested blocks. Event-oriented UI is a special case: you need to have a block inside the main even processing loop of the UI thread. This is already implemented in UI libraries. For example, both WPF and
System.Windows.Forms provides special events you need to handle.
On top of it, there are few special cases when an exception should be caught somewhere in between. Most typically, it should be re-thrown, either as is or as a different exception type (more specialized (semantic) or, more rarely, as more generalized exception). Blocking exception propagation is quite a bad thing, but sometime should be used, usually to recover from exception thrown by "bad" 3rd-party code which is not accessible for patching.
For more detail about these practices, please see my past solutions:
How do i make a loop that will stop when a scrollbar reaches the bottom[
^],
When i run an application an exception is caught how to handle this?[
^],
throw . .then ... rethrowing[
^],
Error Logging and Screen Shot.[
^],
Catching an Exception[
^].
—SA
Submit an article or tip