Hi GS,
Error handling may have to be scattered in the code - this depends upon who
could handle the exception.
A few pointers which might help:
1. Can the exception be mitigated locally (within that method)?
If YES, then catch that specific exception (strongly typed), solve the error
(or do something about it). If the upper layers might have something to do
about this, then rethrow the exception. If you are not going to rethrow, and
this exception might be interesting to the admin, log it locally.
If NOT, let the exception propagate - maybe the upper layers would be able
to handle it. You needn't even have a try-catch block in this case. A catch
block with nothing but a throw statement for that same exception is the same
as not having a catch block.
2. Are you using Disposable types in the try block?
If YES, then add a finally block and dispose the object in it after making
sure it is not null. You would make use of try-finally blocks with no catch
blocks for this; this is good error handling design.
3. Add an unhandled exception handler.
Note that depending upon the application type (ASP.NET, Windows Service
etc.) the way you handle unhandled exceptions would differ. Add your logging
code here. Make sure that the logging code does not take a very long time -
the end use is waiting! In fact, some applications make use of asynchronous
error logging so that performance is not affected.
4. Do NOT catch base exceptions like Exception.
Ideally exceptions should not be hidden by having a catch all block like
'catch(Exception ex)'. This would hide possible flaws in your application -
let them propagate so that you could handle it in a properr way before the
app ships.
For more info on error handling in ASP.NET, check out:
http://www.codeproject.com/aspnet/errorhandlingaspnet.asp