Exception handling is a programming language or computer hardware mechanism designed to handle runtime errors or other problems (exceptions) inside a computer program.

In general, current state will be saved in a predefined location and execution will switch to a predefined handler. Depending on the situation, the handler may later resume the execution at the original location, using the saved information to restore the original state. An exception which will be usually resumed is a page fault, while a division by zero usually cannot be resolved transparently.

From the processing point of view, hardware interrupts are similar to resumable exceptions, except they are usually not related to the current program flow.

Goals of exceptions

Exception handling is intended to facilitate use of reasonable mechanisms for handling erroneous or exceptional situations that arise in programs. Exception handling can be used to pass information about error situations that occur within library code to its users, and selectively respond to those errors.

A possible role of exception handling is to allow the program to continue its normal operation and prevent crashing and displaying of cryptic error messages to the user. In many cases, it is sufficient to stop the program and produce an error report; the difference with systems that do not use exceptions to signal improper program executions is that with proper exception handling, the erroneous condition may be pointed precisely, whereas otherwise it is often detected later, making debugging difficult.

Exception handling makes the signal (computing)-handling techinque used in other languages obsolete.

Exception safety

A piece of code is said to be exception-safe if run-time failures within the code will not produce ill-effects, such as memory leaks, garbled data or invalid output. Exception-safe code must satisfy invariants placed on the code even if exceptions occur. There are several levels of exception safety:

• Failure transparency, operations are guaranteed to succeed and satisfy all requirements even in presence of exceptional situations. (best)
• commit or rollback semantics, operations can fail, but failed operations are guaranteed to have no side effects.
• basic exception safety, partial execution of failed operations can cause side effects, but invariants on the state are preserved (that is, any stored data will contain valid values).
• minimal exception safety, partial execution of failed operations may store invalid data but will not cause a crash.
• no exception safety, no guarantees are made. (worst)

Usually at least basic exception safety is required. Failure transparency is difficult to implement, and is usually not possible in libraries where complete knowledge of the application is not available.

Exception support in programming languages

Certain computer languages such as Ada, C++, D, Objective-C, Java, Eiffel, Ocaml, Python, SML and all .NET CLS-compliant languages have built-in support for exceptions and exception handling. In those languages, the advent of an exception (more precisely, an exception handled by the language) unwinds the stack of function calls until an exception handler is found. That is, if function f has a handler H for exception E, calls function g, which in turn calls function h, and an exception occurs in f, then functions h and g will be terminated and H will handle E.

An example of exception handling in C++:

#include <exception>

int main() {
    try {
        // do something (might throw an exception)
    }
    catch (std::exception& e) {
         // handle exception e
    }
    catch (...) {
         // unknown exception, should not happen
    }
}

In C++, a resource acquisition is initialization technique can be used to clean up resources in exceptional situations.

An example of exception handling in Java:

try {
    // Normal execution path
} catch (ExampleException ee) {
    // Control jumps here if ExampleException or any of its subclasses happen
} catch (Throwable t) {
    // Throwable is the superinterface of all exception classes, so this is equivalent to C++'s catch (...)
} finally {
    // This optional section is executed upon termination of any of the try or catch blocks above
}

An example of exception handling in Python:

try:
    f = file("aFileName")
except EnvironmentError:
    print "Unable to open file"
else:
    try:
        f.write(could_make_error())
    finally:
        f.close()

Some operating systems also have similar features, for example Microsoft Windows has "structured exception handling". An example in C:

int filterExpression (EXCEPTION_POINTERS* ep) {
    ++ep->ContextRecord->Eip;
    return EXCEPTION_CONTINUE_EXECUTION;
}
int main() {
    static int zero;
    __try {
	zero = 1/zero;
	printf ("Past the exception.\n");
    } __except (filterExpression (GetExceptionInformation())) {
	printf ("Handler called.\n");
    }
    return 0;
}

Condition systems

Common Lisp, Dylan, Smalltalk and Windows' structured exception handling have a Condition system which encompasses the aforementioned exception handling systems. In those languages or environments the advent of a condition (a "generalisation of an [exception]" according to Kent Pitman) implies a function call, and only late in the exception handler the decision to unwind the stack may be taken.

This is related to the so-called resumption model of exception handling, in which some exceptions are said to be continuable: it is permitted to return to the expression that signaled an exception, after having taken corrective action in the handler. The condition system is generalized thus: within the handler of a non-serious condition (a.k.a. continuable exception), it is possible to jump to predefined restart points (a.k.a. restarts) that lie between the signaling expression and the condition handler. Restarts are function closed over some lexical environment, allowing the programmer to repair this environment before exiting the condition handler completely or unwinding the stack even partially.

Conditions are a generalization of exceptions. When a condition arises, an appropriate condition handler is searched for and selected, in stack order, to handle the condition. Conditions which do not represent errors may safely go unhandled entirely; their only purpose may be to propagate hints or warnings toward the user. [1]

When a calculation signals a condition, it does not have to abort in the manner of one which raises an exception or error. A condition handler has the option to handle the condition without unwinding the stack, allowing computation to continue.

See also

• Triple fault