Exception handling: Difference between revisions

Revision as of 09:47, 2 October 2023

Revision as of 21:49, 17 October 2023

Line 2:

{{Redirect-distinguish|Error handling|Error detection and correction}}

{{About|computing|knowledge|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 (computing)|execution]] of a [[Computer program|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 [[Computer hardware|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 [[interrupt]]s, or [[operating system]] (OS) [[inter-process communication]] (IPC) facilities like [[Signal (IPC)|signals]]. Some exceptions, especially hardware ones, may be handled so gracefully that execution can resume where it was interrupted.

== Definition ==

{{further|Interrupt#Terminology}}

The definition of an exception is based on the observation that each [[Subroutine|procedure]] has a [[precondition]], a set of circumstances for which it will terminate "normally".<ref name=Cristian>{{cite journal |last1=Cristian |first1=Flaviu |title=Exception Handling and Software Fault Tolerance |journal=Proc. 10th Int. Symp. On Fault Tolerant Computing|date=1980 |issue=6 |pages=531–540 |doi=10.1109/TC.1982.1676035|citeseerx=10.1.1.116.8736|s2cid=18345469 |oclc=1029229019|edition=FTCS-25 reprint}}</ref> An exception handling mechanism allows the procedure to ''raise an exception''{{sfn|Goodenough|1975b|pp=683-684}} if this precondition is violated,<ref name=Cristian/> for example if the procedure has been called on an abnormal set of arguments.

The exception handling mechanism then ''handles'' the exception.{{sfn|Goodenough|1975b|p=684}}

The precondition, and the definition of exception, is [[Subjectivity|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).{{sfn|Black|1982|pp=13-15}} 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.<ref name="Lang" />

Taking a broad view, errors can be considered to be a proper subset of exceptions,{{sfn|Levin|1977|p=5}} and explicit error mechanisms such as errno can be considered (verbose) forms of exception handling.<ref name="Lang">{{cite journal |last1=Lang |first1=Jun |last2=Stewart |first2=David B. |title=A study of the applicability of existing exception-handling techniques to component-based real-time software technology |journal=ACM Transactions on Programming Languages and Systems |date=March 1998 |volume=20 |issue=2 |pages=276 |doi=10.1145/276393.276395|citeseerx=10.1.1.33.3400|s2cid=18875882 |quote=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.}}</ref> 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 [[:wikt:exception|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.<ref name="CLU">{{cite journal |last1=Liskov |first1=B.H. |last2=Snyder |first2=A. |title=Exception Handling in CLU |journal=IEEE Transactions on Software Engineering |date=November 1979 |volume=SE-5 |issue=6 |pages=546–558 |doi=10.1109/TSE.1979.230191 |s2cid=15506879 |url=http://csg.csail.mit.edu/CSGArchives/memos/Memo-155-3.pdf |access-date=19 December 2021}}</ref> 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.{{sfn|Levin|1977|p=4}}

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".<ref name="Kiniry">{{Cite book | doi = 10.1007/11818502_16| chapter = Exceptions in Java and Eiffel: Two Extremes in Exception Design and Application| title = Advanced Topics in Exception Handling Techniques| volume = 4119| pages = 288–300| series = Lecture Notes in Computer Science| year = 2006| last1 = Kiniry | first1 = J. R. | isbn = 978-3-540-37443-5| s2cid = 33283674|url=http://staffwww.dcs.shef.ac.uk/people/A.Simons/remodel/papers/ExceptionsInEiffelAndJava.pdf}}</ref>