Editing Exception handling

{{Short description|Programming language construct for special conditions}}
{{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. 

Exceptions are defined by different layers of a computer system, and the typical layers are CPU-defined [[interrupt]]s, [[operating system]] (OS)-defined [[Signal (IPC)|signals]], [[programming language]]-defined exceptions. Each layer requires different ways of exception handling although they may be interrelated, e.g. a CPU interrupt could be turned into an OS signal. 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]]),<ref>{{harvnb|Keeton|Cavaness|Friesen|2001}}: {{java|ArrayIndexOutOfBoundsException}}</ref> an unavailable resource (like a missing file,<ref>{{harvnb|Keeton|Cavaness|Friesen|2001}}: {{java|FileNotFoundException}}</ref> a network drive error,<ref>{{cite web |title=Unusual error message : java.io.SyncFailedException: sync failed |url=https://groups.google.com/g/h2-database/c/udeVfmkeZuE |website=groups.google.com |access-date=17 November 2023}}</ref> or out-of-memory errors<ref>{{cite web |title=Understand the OutOfMemoryError Exception |url=https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/memleaks002.html |website=docs.oracle.com |access-date=17 November 2023}}</ref>), or that the routine has detected a normal condition that requires special handling, e.g., attention, end of file.<ref>Java: {{java|FileNotFoundException}}</ref> Social pressure is a major influence on the scope of exceptions and use of exception-handling mechanisms, 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>

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.<ref name="CLU"/>

The term "exception" may be misleading because its connotation of "anomaly" indicates that raising an exception is abnormal or unusual,<ref>{{cite web |title=Thesaurus results for EXCEPTION |url=https://www.merriam-webster.com/thesaurus/exception |website=www.merriam-webster.com |access-date=17 November 2023 |language=en}}</ref> 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}}

== History ==
{{main|Interrupt#History|IEEE 754#History|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.<ref name=Smotherman>{{cite web |last1=Smotherman |first1=Mark |title=Interrupts |url=https://people.cs.clemson.edu/~mark/interrupts.html |access-date=4 January 2022}}</ref>
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|Interrupt}}
There is no clear consensus as to the exact meaning of an exception with respect to hardware.<ref>{{cite web |last1=Hyde |first1=Randall |title=Art of Assembly: Chapter Seventeen |url=https://www.plantation-productions.com/Webster/www.artofasm.com/DOS/ch17/CH17-1.html#HEADING1-0 |website=www.plantation-productions.com |access-date=22 December 2021}}</ref> 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|IEEE 754#Exception handling}}

Exception handling in the [[IEEE 754]] [[floating-point arithmetic#Dealing with exceptional cases|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 [[floating-point arithmetict#Dealing with exceptional cases|status flags]] for later checking of whether the exception occurred (see [[C99#IEEE 754 floating-point support|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.<ref name="Xiaoye Li and James Demmel 1994 983–992">{{cite journal |author1=Xiaoye Li|author1-link=Sherry Li |author2=James Demmel | title=Faster Numerical Algorithms via Exception Handling, IEEE Transactions on Computers, 43(8) | year= 1994 | pages=983–992}}</ref>

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 singularity|removable singularities]].<ref name="Xiaoye Li and James Demmel 1994 983–992"/><ref name=grail>{{cite web|url=http://www.cs.berkeley.edu/~wkahan/Grail.pdf|title=A Demonstration of Presubstitution for ∞/∞|author=W.Kahan|date=July 5, 2005|url-status=live|archive-url=https://web.archive.org/web/20120310130507/http://www.cs.berkeley.edu/~wkahan/Grail.pdf|archive-date=March 10, 2012}}</ref><ref>{{cite journal |last1=Hauser |first1=John R. |title=Handling floating-point exceptions in numeric programs |journal=ACM Transactions on Programming Languages and Systems |date=March 1996 |volume=18 |issue=2 |pages=139–174 |doi=10.1145/227699.227701|s2cid=9820157 |doi-access=free }}</ref>

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)|Cluster spacecraft]] launch ended in a catastrophic explosion due in part to the [[Ada (programming language)|Ada]] exception handling policy of aborting computation on arithmetic error. [[William Kahan]] claims the default IEEE 754 exception handling behavior would have prevented this.<ref name=grail />

== In programming languages ==
{{excerpt|Exception handling (programming)}}

== In user interfaces ==

[[Front-end web development]] frameworks, such as [[React (JavaScript library)|React]] and [[Vue.js|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.<ref>{{Cite web|url=https://reactjs.org/docs/error-boundaries.html|title=Error Boundaries|website=React|access-date=2018-12-10}}</ref><ref>{{Cite web|url=https://vuejs.org/v2/api/#errorCaptured|title=Vue.js API|website=Vue.js|access-date=2018-12-10}}</ref> 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 <code>errorCaptured</code><syntaxhighlight lang="javascript">
Vue.component('parent', {
    template: '<div><slot></slot></div>',
    errorCaptured: (err, vm, info) => alert('An error occurred');
})
Vue.component('child', {
    template: '<div>{{ cause_error() }}</div>'
})
</syntaxhighlight>When used like this in markup:<syntaxhighlight lang="html">
<parent>
    <child></child>
</parent>
</syntaxhighlight>The error produced by the child component is caught and handled by the parent component.<ref>{{Cite web|url=https://catchjs.com/Docs/Vue|title=Error handling with Vue.js|website=CatchJS|access-date=2018-12-10}}</ref>

==See also==
* [[Triple fault]]
* [[Data validation]]

==References==
{{reflist|2}}
{{refbegin}}
* {{cite thesis|last1=Black|first1=Andrew P.|url=http://web.cecs.pdx.edu/~black/publications/Black%20D.%20Phil%20Thesis.pdf|citeseerx=10.1.1.94.5554|title=Exception handling: The case against|publisher=University of Oxford|date=January 1982|type=PhD|oclc=123311492}}
* {{Cite conference| doi = 10.1145/1529966.1529967| title = A Pattern of Language Evolution| conference = LISP50: Celebrating the 50th Anniversary of Lisp| pages = 1–10| year = 2008| last1 = Gabriel | first1 = Richard P.| author-link1 = Richard P. Gabriel| last2 = Steele | first2 = Guy L.| author-link2 = Guy L. Steele, Jr.| url = http://www.dreamsongs.com/Files/PatternOfLanguageEvolution.pdf| isbn = 978-1-60558-383-9}}
* {{Cite conference| doi = 10.1145/512976.512997| title = Structured exception handling| conference = Proceedings of the 2nd ACM SIGACT-SIGPLAN symposium on Principles of programming languages - POPL '75| pages = 204–224| date = 1975a<!-- See other paper at: [[Template:Cite doi/10.1145.2F361227.361230]] -->| last = Goodenough | first = John B.<!-- not the physicist -->}}
* {{Cite journal| doi = 10.1145/361227.361230| title = Exception handling: Issues and a proposed notation| url = http://www.cs.colorado.edu/~bec/courses/csci5535-s09/reading/goodenough-exceptions.pdf| journal = Communications of the ACM| volume = 18| issue = 12| pages = 683–696| year = 1975| last = Goodenough | first = John B.<!-- not the physicist -->| ref = {{harvid|Goodenough|1975|b}}<!-- See other paper at: [[Template:Cite doi/10.1145.2F512976.512997]] -->| citeseerx = 10.1.1.122.7791| s2cid = 12935051}}
* {{cite thesis|last1=Levin|first1=Roy|id={{DTIC|ADA043449}}|title=Program Structures for Exceptional Condition Handling|type=PhD|publisher=Carnegie-Mellon University|date=June 1977|url=https://apps.dtic.mil/sti/pdfs/ADA043449.pdf|archive-url=https://web.archive.org/web/20211222205616/https://apps.dtic.mil/sti/pdfs/ADA043449.pdf|url-status=live|archive-date=December 22, 2021}}
* {{cite book |last1=Stroustrup |first1=Bjarne |title=The design and evolution of C++ |date=1994 |publisher=Addison-Wesley |location=Reading, Mass. |isbn=0-201-54330-3 |edition=1st}}
* {{cite conference
|first=Jon L<!-- no period -->
|last=White
|title=NIL - A Perspective
|date=May 1979
|conference=Proceedings of the 1979 Macsyma User's Conference
|url=http://www.softwarepreservation.org/projects/LISP/MIT/White-NIL_A_Perspective-1979.pdf
}}
* {{cite book |last1=Keeton |first1=Brian |last2=Cavaness |first2=Chuck |last3=Friesen |first3=Geoff |title=Special Edition Using Java 2 Standard Edition |date=2001 |publisher=Que Publishing |isbn=978-0-7897-2468-7 |url=https://books.google.com/books?id=yhFxiVyd1MgC&pg=PA89 |language=en}}
{{refend}}

==External links==
* [https://web.archive.org/web/20150929000043/http://www.microsoft.com/msj/0197/exception/exception.aspx A Crash Course on the Depths of Win32 Structured Exception Handling] by [[Matt Pietrek]] - Microsoft Systems Journal (1997)
* Article "[https://db.usenix.org/events/wiess2000/full_papers/dinechin/dinechin.pdf C++ Exception Handling]" by Christophe de Dinechin
* Article "[http://java.sun.com/developer/technicalArticles/Programming/exceptions2/index.html Exceptional practices]" by Brian Goetz
* Article "[http://perl.com/pub/a/2002/11/14/exception.html Object Oriented Exception Handling in Perl]" by Arun Udaya Shankar
* Article "[http://oreillynet.com/pub/a/network/2003/05/05/cpluspocketref.html Programming with Exceptions in C++]" by Kyle Loudon
* Article "[http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html Unchecked Exceptions - The Controversy]"
* Conference slides [http://www.eecs.berkeley.edu/~wkahan/Boulder.pdf Floating-Point Exception-Handling policies (pdf p. 46) ] by William Kahan
* [http://c2.com/cgi/wiki?CategoryException Descriptions from Portland Pattern Repository]
* [https://web.archive.org/web/20020405175011/http://www.mindview.net/Etc/Discussions/CheckedExceptions Does Java Need Checked Exceptions?]

{{Data types}}
{{Authority control}}

{{DEFAULTSORT:Exception Handling}}
<!--Categories-->
[[Category:Control flow]]
[[Category:Software anomalies]]