Catching Exceptions

Throwing a particular exception type enables the type itself to identify the problem. It is not necessary, in other words, to catch the exception and use a switch statement on the exception message to determine what action to take in light of the exception. Instead, C# allows for multiple catch blocks, each targeting a specific exception type, as Listing 10.2 shows.

Listing 10.2. Catching Different Exception Types

public sealed class Program {   public static  void Main()   {       try       {               // ...               throw  new ApplicationException(                         "Arbitrary exception");               // ...       }       catch (NullReferenceException exception)       {           // Handle NullReferenceException       }       catch (ArgumentException exception)       {           // Handle ArgumentException       }       catch (ApplicationException exception)       {           // Handle ApplicationException        }       catch (SystemException exception)       {           // Handle SystemException       }       catch (Exception exception)       {           // Handle Exception       }    }  }

Listing 10.2 has five catch blocks, each handling a different type of exception. When an exception occurs, the execution will jump to the catch block with the exception type that most closely matches. The closeness of a match is determined by the inheritance chain. For example, even though the exception thrown is of type System.Exception, this "is a" relationship occurs through inheritance because System.ApplicationException derives from System.Exception. Since ApplicationException most closely matches the exception thrown, catch(ApplicationException ...) will catch the exception instead of the catch(Exception ...) block.

Catch blocks must appear in order, from most specific to most general, to avoid a compile error. For example, moving the catch(Exception ...) block before any of the other exceptions will result in a compile error, since all prior exceptions derive from System.Exception at some point in their inheritance chain.

Language Contrast: JavaException Specifiers

C# has no equivalent for Java's exception specifiers. With exception specifiers, the Java compiler is able to verify that all possible exceptions thrown within a function (or a function's call hierarchy) are either caught or declared as possibly rethrown. The C# team considered this option and concluded that the maintenance burden that it imposed was not worth the perceived benefit. Therefore, it is not necessary to maintain a list of all possible exceptions throughout a particular call stack, but neither is it possible to easily determine the possible exceptions. (As it turns out, this wasn't possible for Java either. Calling virtual methods or using late binding, such as reflection, made it impossible to fully resolve at compile time what exceptions a method could possibly throw.)