Exception handling

"Error handling" redirects here. Not to be confused with Error detection and correction.

This article is about computing. For knowledge, see fact checking and problem solving.

In computing and computer programming, exception handling is the process of responding to the occurrence of exceptions – anomalous or exceptional conditions requiring special processing – during the execution of a program. In general, an exception breaks the normal flow of execution and executes a pre-registered exception handler; the details of how this is done depend on whether it is a hardware or software exception and how the software exception is implemented.

Exception handling, if provided, is facilitated by specialized programming language constructs, hardware mechanisms like interrupts, or operating system (OS) inter-process communication (IPC) facilities like signals. Some exceptions, especially hardware ones, may be handled so gracefully that execution can resume where it was interrupted.

Definition

Further information: Interrupt § Terminology

The definition of an exception is based on the observation that each procedure has a precondition, a set of circumstances for which it will terminate "normally".^[1] An exception handling mechanism allows the procedure to raise an exception^[2] if this precondition is violated,^[1] for example if the procedure has been called on an abnormal set of arguments.

The exception handling mechanism then handles the exception.^[3] The precondition, and the definition of exception, is subjective. The set of "normal" circumstances is defined entirely by the programmer, e.g. the programmer may deem division by zero to be undefined, hence an exception, or devise some behavior such as returning zero or a special "ZERO DIVIDE" value (circumventing the need for exceptions).^[4] Common exceptions include an invalid argument (e.g. value is outside of the domain of a function), an unavailable resource (like a missing file, a hard disk error, or out-of-memory errors), or that the routine has detected a normal condition that requires special handling, e.g., attention, end of file.

Exception handling solves the semipredicate problem, in that the mechanism distinguishes normal return values from erroneous ones. In languages without built-in exception handling such as C, routines would need to signal the error in some other way, such as the common return code and errno pattern.^[5]

Taking a broad view, errors can be considered to be a proper subset of exceptions,^[6] and explicit error mechanisms such as errno can be considered (verbose) forms of exception handling.^[5] The term "exception" is preferred to "error" because it does not imply that anything is wrong - a condition viewed as an error by one procedure or programmer may not be viewed that way by another.

Even the term "exception" may be misleading because its typical connotation of "outlier" indicates that something infrequent or unusual has occurred, when in fact raising the exception may be a normal and usual situation in the program.^[7] For example, suppose a lookup function for an associative array throws an exception if the key has no value associated. Depending on context, this "key absent" exception may occur much more often than a successful lookup.^[8]

A major influence on the scope and use of exceptions is social pressure, i.e. "examples of use, typically found in core libraries, and code examples in technical books, magazine articles, and online discussion forums, and in an organization’s code standards".^[9]

History

Main articles: Interrupt § History, IEEE 754 § History, and Exception handling (programming) § History

The first hardware exception handling was found in the UNIVAC I from 1951. Arithmetic overflow executed two instructions at address 0 which could transfer control or fix up the result.^[10] Software exception handling developed in the 1960s and 1970s. Exception handling was subsequently widely adopted by many programming languages from the 1980s onward.

Hardware exceptions

Main article: Interrupt

There is no clear consensus as to the exact meaning of an exception with respect to hardware.^[11] From the implementation point of view, it is handled identically to an interrupt: the processor halts execution of the current program, looks up the interrupt handler in the interrupt vector table for that exception or interrupt condition, saves state, and switches control.

IEEE 754 floating-point exceptions

Main article: IEEE 754 § Exception handling

Exception handling in the IEEE 754 floating-point standard refers in general to exceptional conditions and defines an exception as "an event that occurs when an operation on some particular operands has no outcome suitable for every reasonable application. That operation might signal one or more exceptions by invoking the default or, if explicitly requested, a language-defined alternate handling."

By default, an IEEE 754 exception is resumable and is handled by substituting a predefined value for different exceptions, e.g. infinity for a divide by zero exception, and providing status flags for later checking of whether the exception occurred (see C99 programming language for a typical example of handling of IEEE 754 exceptions). An exception-handling style enabled by the use of status flags involves: first computing an expression using a fast, direct implementation; checking whether it failed by testing status flags; and then, if necessary, calling a slower, more numerically robust, implementation.^[12]

The IEEE 754 standard uses the term "trapping" to refer to the calling of a user-supplied exception-handling routine on exceptional conditions, and is an optional feature of the standard. The standard recommends several usage scenarios for this, including the implementation of non-default pre-substitution of a value followed by resumption, to concisely handle removable singularities.^[12][13][14]

The default IEEE 754 exception handling behaviour of resumption following pre-substitution of a default value avoids the risks inherent in changing flow of program control on numerical exceptions. For example, the 1996 Cluster spacecraft launch ended in a catastrophic explosion due in part to the Ada exception handling policy of aborting computation on arithmetic error. William Kahan claims the default IEEE 754 exception handling behavior would have prevented this.^[13]

In programming languages

This section is an excerpt from Exception handling (programming).[edit]

In computer programming, several language mechanisms exist for exception handling. The term exception is typically used to denote a data structure storing information about an exceptional condition. One mechanism to transfer control, or raise an exception, is known as a throw; the exception is said to be thrown. Execution is transferred to a catch.

Programming languages differ substantially in their notion of what an exception is. Contemporary languages can roughly be divided into two groups:^{[15][note 1]}

• Languages where exceptions are designed to be used as flow control structures: Ada, Modula-3, ML, OCaml, PL/I, Python, and Ruby fall in this category. For example, Python's iterators throw StopIteration exceptions to signal that there are no further items produced by the iterator.^[16]
• Languages where exceptions are only used to handle abnormal, unpredictable, erroneous situations: C++,^[17] Java,^[18] C#, Common Lisp, Eiffel, and Modula-2.

In user interfaces

Front-end web development frameworks, such as React and Vue, have introduced error handling mechanisms where errors propagate up the user interface (UI) component hierarchy, in a way that is analogous to how errors propagate up the call stack in executing code.^[19][20] Here the error boundary mechanism serves as an analogue to the typical try-catch mechanism. Thus a component can ensure that errors from its child components are caught and handled, and not propagated up to parent components.

For example, in Vue, a component would catch errors by implementing errorCaptured

Vue.component('parent', {  template: '<div><slot></slot></div>',  errorCaptured: (err, vm, info) => alert('An error occurred'); }) Vue.component('child', {  template: '<div>{{ cause_error() }}</div>' }) 

When used like this in markup:

<parent> <child></child> </parent> 

The error produced by the child component is caught and handled by the parent component.^[21]

See also

• Triple fault
• Data validation

Notes

1. PL/I used dynamically scoped exceptions. PL/I exception handling included events that are not errors, e.g., attention, end-of-file, modification of listed variables.^{[citation needed]}

References

1. Cristian, Flaviu (1980). "Exception Handling and Software Fault Tolerance". Proc. 10th Int. Symp. On Fault Tolerant Computing (FTCS-25 reprint ed.) (6): 531–540. CiteSeerX 10.1.1.116.8736. doi:10.1109/TC.1982.1676035. OCLC 1029229019. S2CID 18345469.
2. Goodenough 1975b, pp. 683–684.
3. Goodenough 1975b, p. 684.
4. Black 1982, pp. 13–15.
5. Lang, Jun; Stewart, David B. (March 1998). "A study of the applicability of existing exception-handling techniques to component-based real-time software technology". ACM Transactions on Programming Languages and Systems. 20 (2): 276. CiteSeerX 10.1.1.33.3400. doi:10.1145/276393.276395. S2CID 18875882. Perhaps the most common form of exception-handling method used by software programmers is the "return-code" technique that was popularized as part of C and UNIX.
6. Levin 1977, p. 5.
7. Liskov, B.H.; Snyder, A. (November 1979). "Exception Handling in CLU" (PDF). IEEE Transactions on Software Engineering. SE-5 (6): 546–558. doi:10.1109/TSE.1979.230191. S2CID 15506879. Retrieved 19 December 2021.
8. Levin 1977, p. 4.
9. Kiniry, J. R. (2006). "Exceptions in Java and Eiffel: Two Extremes in Exception Design and Application". Advanced Topics in Exception Handling Techniques (PDF). Lecture Notes in Computer Science. Vol. 4119. pp. 288–300. doi:10.1007/11818502_16. ISBN 978-3-540-37443-5. S2CID 33283674.
10. Smotherman, Mark. "Interrupts". Retrieved 4 January 2022.
11. Hyde, Randall. "Art of Assembly: Chapter Seventeen". www.plantation-productions.com. Retrieved 22 December 2021.
12. Xiaoye Li; James Demmel (1994). "Faster Numerical Algorithms via Exception Handling, IEEE Transactions on Computers, 43(8)": 983–992. {{cite journal}}: Cite journal requires |journal= (help)
13. W.Kahan (July 5, 2005). "A Demonstration of Presubstitution for ∞/∞" (PDF). (PDF) from the original on March 10, 2012.
14. Hauser, John R. (March 1996). "Handling floating-point exceptions in numeric programs". ACM Transactions on Programming Languages and Systems. 18 (2): 139–174. doi:10.1145/227699.227701. S2CID 9820157.
15. Kiniry, J. R. (2006). "Exceptions in Java and Eiffel: Two Extremes in Exception Design and Application". Advanced Topics in Exception Handling Techniques (PDF). Lecture Notes in Computer Science. Vol. 4119. pp. 288–300. doi:10.1007/11818502_16. ISBN 978-3-540-37443-5.
16. "Built-in Exceptions — Python 3.10.4 documentation". docs.python.org. Retrieved 17 May 2022.
17. "Stroustrup: C++ Style and Technique FAQ". www.stroustrup.com. from the original on 2 February 2018. Retrieved 5 May 2018.
18. Bloch, Joshua (2008). "Item 57: Use exceptions only for exceptional situations". Effective Java (Second ed.). Addison-Wesley. p. 241. ISBN 978-0-321-35668-0.
19. "Error Boundaries". React. Retrieved 2018-12-10.
20. "Vue.js API". Vue.js. Retrieved 2018-12-10.
21. "Error handling with Vue.js". CatchJS. Retrieved 2018-12-10.

• Black, Andrew P. (January 1982). Exception handling: The case against (PDF) (PhD). University of Oxford. CiteSeerX 10.1.1.94.5554. OCLC 123311492.
• Gabriel, Richard P.; Steele, Guy L. (2008). A Pattern of Language Evolution (PDF). LISP50: Celebrating the 50th Anniversary of Lisp. pp. 1–10. doi:10.1145/1529966.1529967. ISBN 978-1-60558-383-9.
• Goodenough, John B. (1975a). Structured exception handling. Proceedings of the 2nd ACM SIGACT-SIGPLAN symposium on Principles of programming languages - POPL '75. pp. 204–224. doi:10.1145/512976.512997.
• Goodenough, John B. (1975). "Exception handling: Issues and a proposed notation" (PDF). Communications of the ACM. 18 (12): 683–696. CiteSeerX 10.1.1.122.7791. doi:10.1145/361227.361230. S2CID 12935051.
• Levin, Roy (June 1977). Program Structures for Exceptional Condition Handling (PDF) (PhD). Carnegie-Mellon University. DTIC ADA043449. (PDF) from the original on December 22, 2021.
• Stroustrup, Bjarne (1994). The design and evolution of C++ (1st ed.). Reading, Mass.: Addison-Wesley. ISBN 0-201-54330-3.
• White, Jon L (May 1979). NIL - A Perspective (PDF). Proceedings of the 1979 Macsyma User's Conference.

External links

• by Matt Pietrek - Microsoft Systems Journal (1997)
• Article "C++ Exception Handling" by Christophe de Dinechin
• Article "Exceptional practices" by Brian Goetz
• Article "Object Oriented Exception Handling in Perl" by Arun Udaya Shankar
• Article "Programming with Exceptions in C++" by Kyle Loudon
• Article "Unchecked Exceptions - The Controversy"
• Conference slides Floating-Point Exception-Handling policies (pdf p. 46) by William Kahan
• Descriptions from Portland Pattern Repository