There is no requirement, and no ability, in C# for a function member to programmatically declare the exceptions it might throw. The only way to do so is in the API documentation. This has two consequences:

The following example demonstrates the familiar try...catch...finally exception-handling syntax, along with new catch syntax introduced by C#:

try {
    // code that might throw an exception

} catch (ExceptionClass1 ex1) {        // catch clause 1
    // code to handle exceptions of class ExceptionClass1
    // with access to the thrown exception named ex1

} catch (ExceptionClass2) {        // catch clause 2
    // code to handle exceptions of class ExceptionClass2
    // but without access to the Exception instance

} catch {     // catch clause 3
    // code to handle any Exception, but without access
    // to the Exception instance

} finally {
    // code that executes no matter whether
    // the try block succeeds or fails
}

The example shows that

Throwing exceptions is the same in C# as in Java. For example:

throw new ExceptionClass();

C# introduces a shorthand syntax for rethrowing caught exceptions: the throw statement with no parameters. This is required when using the new catch syntax described in the preceding section. For example:

try {
    // Some code
} catch {
    // Some exception handling code
    // Rethrow the caught exception
    throw;
}

The java.lang.Throwable class is the root of the Java exception class hierarchy. Two classes derive directly from Throwable: java.lang.Exception and java.lang.Error. Derived from Exception is a class named java.lang.RuntimeException. The Exception, Error, and RuntimeException subclasses of Throwable are central to the Java classification of exceptions into the checked and unchecked categories.

Unchecked exceptions are those derived from either the Error or RuntimeException class. The compiler makes no attempt to ensure that these exceptions are handled by the developer since they generally occur because of a run-time or program error that should be fixed.

Checked exceptions are those that the compiler ensures are caught and handled within the code or are declared in the throws clause of the method declaration. Checked exceptions include all exceptions derived from java.lang.Exception, excluding RuntimeException and its subclasses.

Because C# function members cannot declare exceptions, the compiler makes no attempt to ensure that exceptions are caught and handled correctly. All .NET exceptions can be considered to be unchecked exceptions in Java terminology.

.NET takes a simpler approach to classifying exceptions based on whether it is a system or an application-related exception. This is merely a convention and is not enforced by the compiler or the runtime.

The root of the exception hierarchy in .NET is System.Exception. System exceptions are represented by System.SystemException and application exceptions by System.ApplicationException, both of which are derived from System.Exception.

Table 6-1 compares the functionality of .NET’s System.Exception class with that of the Java java.lang.Throwable class. Although not a part of either language specification, the use of exceptions is tightly integrated with both Java and C# and is appropriate to this chapter. Java and .NET both rely on the exception inheritance hierarchy as a classification mechanism to support the use of the catch clause.