This web site uses cookies. By using the site you accept the cookie policy.This message is for compliance with the UK ICO law.

C# Programming
.NET 1.1+

C# Exception Handling

The thirty-fourth part of the C# Fundamentals tutorial begins a review of exception handling. When an unexpected event occurs, unhandled exceptions cause a program to exit abnormally. Correct handling permits the graceful recovery from an error condition.

What is an Exception?

An exception is an error that occurs during program execution. Generally, an exception describes an unexpected event. For example, an exception will occur if a program requests more memory than the operating system can provide. This exception is known as an Out of Memory Exception.

The Exception Class Hierarchy

When an exception occurs normal processing of the code ceases. An object is generated that contains information relating to the error. This object is an instance of an Exception class. The most basic of the exception classes is Exception, defined in the System namespace.

The exception classes are organised into a hierarchy with Exception at the top. Beneath the Exception class are SystemException and ApplicationException. The SystemException class has further derived subclasses, each representing a specific exception type that can be raised in response to a system error. The ApplicationException class is a base class from which custom application exceptions may be derived.

NB: Subclass and base class are object-oriented programming terms. Object oriented programming is beyond the scope of the C# Fundamentals tutorial and will be described in a future series of articles.

System Exceptions

There are many system exceptions that may be raised, or thrown, when a problem occurs. These cause the generation of an object based on its own specialised exception class derived from SystemException. Examples include:

  • ArithmeticException. Thrown when an error occurs during an arithmetic operation, casting or converting.
  • DivideByZeroException. Thrown when an attempt to divide a value by zero occurs. The DivideByZeroException is a more specialised version of ArithmeticException.
  • OverflowException. Thrown when an error occurs during an arithmetic operation or during casting or converting because the resultant value is too large or small. The OverflowException is derived from ArithmeticException.
  • OutOfMemoryException. Thrown when the available memory is insufficient to continue execution.

The above list gives a small sample of exception classes within the hierarchy. A much more comprehensive list can be found in the System Exceptions Hierarchy page of Microsoft's MSDN web site.

Application Exceptions

Application exceptions are those that you define. They can be generic, for example WordProcessorException, or specialised, such as LeftMarginTooSmallException. Of course, neither of these exceptions exists within the .NET framework; they must be created before use. Application exceptions will not be discussed until the next article, which investigates programmatically throwing exceptions.

Handling Exceptions

Unhandled Exceptions

When an exception occurs the program flow for the executing method is interrupted. If the exception is not handled explicitly, the method exits and the exception is propagated to the calling function. This calling method has the opportunity to handle the error. This process continues until the exception is handled by the program or it reaches the C# runtime system.

An unhandled exception that reaches the C# runtime system causes the immediate, abnormal termination of the program. This can be a problem as the exception is reported to the user as a message or dialog box containing standard information and technical details that may be misunderstood. During debugging this may be useful but in a production system it is generally considered unacceptable. It can also permit the user to attempt to continue running a program that, due to errors, has become unstable; note the Continue button in the error dialog box below:

Unhandled Exception Message

29 March 2007