Foundations of Programming - Karl Seguin

Chapter 8 - Back to Basics: Exceptions
Throwing Exceptions
There isn't one magic rule to throwing exceptions like there is for catching them (again, that rule is don't
catch exceptions unless you can actually handle them). Nonetheless throwing exceptions, whether or
not they be your own (which we'll cover next), is still pretty simple. First we'll look at the actual
mechanics of throwing exceptions, which relies on the throw statement. Then we'll examine when and
why you actually want to throw exceptions.
Throwing Mechanics
You can either throw a new exception, or rethrow a caught exception. To throw a new exception, simply
create a new exception and throw it.
throw new Exception("something bad happened!");
//or
Exception ex = new Exception("something bad happened");
throw ex;
I added the second example because some developers think exceptions are some special/unique case -
but the truth is that they are just like any other object (except they inherit from System.Exception
which in turn inherits from System.Object). In fact, just because you create a new exception
doesn't mean you have to throw it - although you probably always would.
On occasion you'll need to rethrow an exception because, while you can't handle the exception, you still
need to execute some code when an exception occurs. The most common example is having to rollback
a transaction on failure:
ITransaction transaction = null;
try
{
transaction = session.BeginTransaction();
// do some work
transaction.Commit();
}
catch
{
if (transaction != null) { transaction.Rollback(); }
throw;
}
finally
{
//cleanup
}
In the above example our vanilla throw statement makes our catch transparent. That is, a handler up
the chain of execution won't have any indication that we caught the exception. In most cases, this is
Foundations of Programming Copyright © Karl Seguin www.codebetter.com
67