Foundations of Programming - Karl Seguin

Chapter 8 - Back to Basics: Exceptions
what we want - rolling back our transaction really doesn't help anyone else handle the exception.
However, there's a way to rethrow an exception which will make it look like the exception occurred
within our code:
catch (HibernateException ex)
{
if (transaction != null) { transaction.Rollback(); }
throw ex;
}
By explicitly rethrowing the exception, the stack trace is modified so that the rethrowing line appears to
be the source. This is almost always certainly a bad idea, as vital information is lost. So be careful how
you rethrow exceptions - the difference is subtle but important.
If you find yourself in a situation where you think you want to rethrow an exception with your handler
as the source, a better approach is to use a nested exception:
catch (HibernateException ex)
{
if (transaction != null) { transaction.Rollback(); }
throw new Exception("Email already in use", ex);
}
This way the original stack trace is still accessible via the InnerException property exposed by all
exceptions.
When To Throw Exceptions
It's important to know how to throw exceptions. A far more interesting topic though is when and why
you should throw them. Having someone else's unruly code bring down your application is one thing.
Writing your own code that'll do the same thing just seems plain silly. However, a good developer isn't
afraid to judicially use exceptions.
There are actually two levels of thought on how exceptions should be used. The first level, which is
universally accepted, is that you shouldn't hesitate to raise an exception whenever a truly exceptional
situation occurs. My favorite example is the parsing of configuration files. Many developers generously
use default values for any invalid entries. This is ok in some cases, but in others it can put the system in
an unreliable or unexpected state. Another example might be a Facebook application that gets an
unexpected result from an API call. You could ignore the error, or you could raise an exception, log it (so
that you can fix it, since the API might have changed) and present a helpful message to your users.
The other belief is that exceptions shouldn't just be reserved for exceptional situations, but for any
situation in which the expected behavior cannot be executed. This approach is related to the design by
Foundations of Programming Copyright © Karl Seguin www.codebetter.com
68