Exception handling: Difference between revisions

Revision as of 04:12, 1 December 2023

Latest revision as of 07:21, 30 July 2025

(3 intermediate revisions by 3 users not shown)

Line 1:

{{Short description|Programming language construct for special conditions}}

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

{{About|computing|knowledge|factFact checking|and|problemProblem 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.

Line 9 ⟶ 10:

{{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.IEEE 10thTransactions Int.on Symp.Computers 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>

Line 46 ⟶ 47:

[[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.js]], a component would catch errors by implementing <code>errorCaptured</code><syntaxhighlight lang="javascript">

{{pre|

{{codett|2=js|1=Vue.component('parent', {}}

{{codett|2=vue |template: '<div><slot></slot></div>',}}

{{codett|2=js|1=errorCaptured: (err, vm, info) => alert('An error occurred');}}

})

{{codett|2=js|1=Vue.component('child', {}}

{{codett|2=vue |template: '<div>{{((}} cause_error() {{))}}</div>'}}

})

}}

</syntaxhighlight>When used like this in markup:<syntaxhighlight lang="html">

When used like this in markup:

<syntaxhighlight lang="html">

<parent>

<child></child>

</parent>

</syntaxhighlight>

</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==