Editing Control flow (section)

=== Exceptions ===
{{main article|Exception handling}}
Modern languages have a specialized structured construct for exception handling which does not rely on the use of <code>GOTO</code> or (multi-level) breaks or returns. For example, in C++ one can write:

<syntaxhighlight lang="cpp">
try {
    xxx1                                  // Somewhere in here
    xxx2                                  //     use: '''throw''' someValue;
    xxx3
} catch (someClass& someId) {             // catch value of someClass
    actionForSomeClass 
} catch (someType& anotherId) {           // catch value of someType
    actionForSomeType
} catch (...) {                           // catch anything not already caught
    actionForAnythingElse
}
</syntaxhighlight>

Any number and variety of <code>catch</code> clauses can be used above. If there is no <code>catch</code> matching a particular <code>throw</code>, control percolates back through subroutine calls and/or nested blocks until a matching <code>catch</code> is found or until the end of the main program is reached, at which point the program is forcibly stopped with a suitable error message.

Via C++'s influence, <code>catch</code> is the keyword reserved for declaring a pattern-matching exception handler in other languages popular today, like Java or C#. Some other languages like Ada use the keyword <code>exception</code> to introduce an exception handler and then may even employ a different keyword (<code>when</code> in Ada) for the pattern matching. A few languages like [[AppleScript]] incorporate placeholders in the exception handler syntax to automatically extract several pieces of information when the exception occurs. This approach is exemplified below by the <code>on error</code> construct from AppleScript:<!-- Here, it would help to explain what all those "from", "to", and "partial results" bits do.-->

<syntaxhighlight lang = "applescript">
try
    set myNumber to myNumber / 0
on error e  number n  from f  to t  partial result pr
    if ( e = "Can't divide by zero" ) then display dialog "You must not do that"
end try
</syntaxhighlight>

David Watt's 2004 textbook also analyzes exception handling in the framework of sequencers (introduced in this article in the section on early exits from loops). Watt notes that an abnormal situation, generally exemplified with arithmetic overflows or [[input/output]] failures like file not found, is a kind of error that "is detected in some low-level program unit, but [for which] a handler is more naturally located in a high-level program unit". For example, a program might contain several calls to read files, but the action to perform when a file is not found depends on the meaning (purpose) of the file in question to the program and thus a handling routine for this abnormal situation cannot be located in low-level system code. Watts further notes that introducing status flags testing in the caller, as single-exit structured programming or even (multi-exit) return sequencers would entail, results in a situation where "the application code tends to get cluttered by tests of status flags" and that "the programmer might forgetfully or lazily omit to test a status flag. In fact, abnormal situations represented by status flags are by default ignored!" Watt notes that in contrast to status flags testing, exceptions have the opposite [[Default (computer science)|default behavior]], causing the program to terminate unless the program deals with the exception explicitly in some way, possibly by adding explicit code to ignore it. Based on these arguments, Watt concludes that jump sequencers or escape sequencers are less suitable as a dedicated exception sequencer with the semantics discussed above.<ref>{{cite book|author1=David Anthony Watt|author2=William Findlay|title=Programming language design concepts|year=2004|publisher=John Wiley & Sons|isbn=978-0-470-85320-7|pages=221–222}}</ref>

In Object Pascal, D, Java, C#, and Python a <code>finally</code> clause can be added to the <code>try</code> construct. No matter how control leaves the <code>try</code> the code inside the <code>finally</code> clause is guaranteed to execute. This is useful when writing code that must relinquish an expensive resource (such as an opened file or a database connection) when finished processing:

<syntaxhighlight lang="csharp">
FileStream stm = null;                    // C# example
try
{
    stm = new FileStream("logfile.txt", FileMode.Create);
    return ProcessStuff(stm);             // may throw an exception
} 
finally
{
    if (stm != null)
        stm.Close();
}
</syntaxhighlight>

Since this pattern is fairly common, C# has a special syntax:

<syntaxhighlight lang="csharp">
using (var stm = new FileStream("logfile.txt", FileMode.Create))
{
    return ProcessStuff(stm); // may throw an exception
}
</syntaxhighlight>

Upon leaving the <code>using</code>-block, the compiler guarantees that the <code>stm</code> object is released, effectively [[Name binding|binding]] the variable to the file stream while abstracting from the side effects of initializing and releasing the file. Python's <code>with</code> statement and Ruby's block argument to <code>File.open</code> are used to similar effect.

All the languages mentioned above define standard exceptions and the circumstances under which they are thrown. Users can throw exceptions of their own; C++ allows users to throw and catch almost any type, including basic types like <code>int</code>, whereas other languages like Java are less permissive.