Game Development Reference
// Code that performs cleanup \ rollback
Just calling throw alone will re-throw the exact same exception object that arrived
at the catch statement in the first place.
Also, be sure to add a semantic value if you re-throw an exception under a differ-
ent type. Sometimes you may wish to take a few specific exceptions and re-throw
them under a more generalized type, but it is advisable to at least attach the old
exception as the inner exception property when re-throwing it. That way, the orig-
inal exception is readily available if there is a need for re-specialization.
Lastly, it is bad design to use exceptions as a means of returning information from
a method. One reason is that exception handling is fairly slow, so overuse and mis-
use of exception handling can introduce many performance bottlenecks into your
Structured Exception Handlers
There are some rules that should be followed when building your exception han-
dlers and deciding what exception types to catch. Never catch a base-type excep-
tion when you are always expecting a more specialized one. For example, do not
catch System.Exception when the only exception that will ever be thrown is a
System.ArgumentNullException . Generic handlers create many problems, and should
be avoided whenever possible. A general rule of thumb is that System.Exception
should only ever be caught once per thread.
If you want more reasoning behind this rule, consider the following example.
Imagine that you build a library that offers fairly basic functionality, and it is used
by a Windows Forms application. Now, normally a method in this library will
throw System.ArgumentNullException when a specified parameter is null . If the
Windows Forms application has a structured exception handler that catches
System.Exception , error handling will work as expected in a perfect situation. In the
event that the library assembly cannot be referenced by the Windows Forms appli-
cation because it is missing, the Common Language Runtime will throw a
System.IO.FileNotFoundException, indicating that the library assembly could not be
found. When this exception occurs, the Windows Forms application believes that
a null parameter was specified, when in reality the entire library could not be found.
However, if the Windows Forms application did not catch generic exceptions, this
problem would be avoided.