Foundations of Programming - Karl Seguin

{
}
Chapter 8 - Back to Basics: Exceptions
categoryId = 1;
The problem with the above code is that regardless of the type of exception thrown, it'll be handled the
same way. But does setting the categoryId to a default value of 1 actually handle an
OutOfMemoryException? Instead, the above could should catch a specific exception:
int categoryId;
try
{
categoryId = int.Parse(Request.QueryString["categoryId"])
}
catch(FormatException)
{
categoryId = -1;
}
(an even better approach would be the use the int.TryParse function introduced in .NET 2.0 -
especially considering that int.Parse can throw two other types of exceptions that we'd want to
handle the same way, but that's besides the point).
Logging
Even though most exceptions are going to go unhandled, you should still log each and every one of
them. Ideally you'll centralize your logging - an HttpModule's OnError event is your best choice for an
ASP.NET application or web service. I've often seen developers catch exceptions where they occur only
to log and rethrow (more on rethrowing in a bit). This causes
a lot of unnecessary and repetitive code - better to let
exceptions bubble up through your code and log all
exceptions at the outer edge of your system. Exactly which
logging implementation you use is up to you and will depend
on the criticalness of your system. Maybe you'll want to be
notified by email as soon as exceptions occur, or maybe you
can simply log it to a file or database and either review it
daily or have another process send you a daily summary.
Many developers leverage rich logging frameworks such as
log4net or Microsoft's Logging Application Block.
Cleaning Up
In the previous chapter we talked about deterministic finalization with respect to the lazy nature of the
garbage collector. Exceptions prove to be an added complexity as their abrupt nature can cause
Dispose not to be called. A failed database call is a classic example:
Foundations of Programming Copyright © Karl Seguin www.codebetter.com
65
A word of warning based on a bad
personal experience: some types of
exceptions tend to cluster. If you
choose to send out emails
whenever an exception occurs you
can easily flood your mail server . A
smart logging solution should
probably implement some type of
buffering or aggregation.