Content deleted Content added
→Criticism: see source I added in Go_(programming_language)#Omissions. exception handling was omitted on initial release due to lack of a design, not ideology. Also remove irrelevant sources duplicated from the Go article |
Citation bot (talk | contribs) Alter: journal, pages. Add: s2cid, pages, issue. Formatted dashes. | Use this bot. Report bugs. | Suggested by Abductive | Category:Software anomalies | #UCB_Category 11/39 |
||
Line 6:
== Definition ==
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.
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"/> 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"/>
Line 41:
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#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 }}</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 />
Line 197:
</ref> Checked exceptions can, at [[compile time]], reduce the incidence of unhandled exceptions surfacing at [[Run time (program lifecycle phase)|runtime]] in a given application.
Kiniry writes that "As any Java programmer knows, the volume of <code>[[try catch]]</code> code in a typical Java application is sometimes larger than the comparable code necessary for explicit formal parameter and return value checking in other languages that do not have checked exceptions. In fact, the general consensus among in-the-trenches Java programmers is that dealing with checked exceptions is nearly as unpleasant a task as writing documentation. Thus, many programmers report that they “resent” checked exceptions.".<ref name="Kiniry"/> [[Martin Fowler (software engineer)|Martin Fowler]] has written "...on the whole I think that exceptions are good, but Java checked exceptions are more trouble than they are worth."<ref name=Eckel/> As of 2006 no major programming language has followed Java in adding checked exceptions.<ref name=Eckel>{{cite book |last1=Eckel |first1=Bruce |title=Thinking in Java |date=2006 |publisher=Prentice Hall |___location=Upper Saddle River, NJ |isbn=0-13-187248-6 |pages=
[[Anders Hejlsberg]] describes two concerns with checked exceptions:<ref name=Trouble>{{cite web |url=https://www.artima.com/articles/the-trouble-with-checked-exceptions|title=The Trouble with Checked Exceptions: A Conversation with Anders Hejlsberg, Part II |author1=Bill Venners |author2=[[Bruce Eckel]] |date=August 18, 2003 |access-date=4 January 2022}}</ref>
Line 207:
==== Similar mechanisms ====
The roots of checked exceptions go back to the [[CLU programming language]]'s notion of exception specification.<ref name=Mindview/> A function could raise only exceptions listed in its type, but any leaking exceptions from called functions would automatically be turned into the sole runtime exception, {{code|failure}}, instead of resulting in compile-time error.<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> Later, [[Modula-3]] had a similar feature.<ref>{{cite web |url=http://www1.cs.columbia.edu/graphics/modula3/tutorial/www/m3_23.html#SEC23 |title=Modula-3 - Procedure Types |publisher=.cs.columbia.edu |date=1995-03-08 |access-date=2011-12-15 |url-status=live |archive-url=https://web.archive.org/web/20080509143753/http://www1.cs.columbia.edu/graphics/modula3/tutorial/www/m3_23.html#SEC23 |archive-date=2008-05-09 }}</ref> These features don't include the compile time checking that is central in the concept of checked exceptions.<ref name=Mindview>{{cite web |url=http://www.mindview.net/Etc/Discussions/CheckedExceptions |archive-url=https://web.archive.org/web/20020405175011/http://www.mindview.net/Etc/Discussions/CheckedExceptions |url-status=dead |archive-date=2002-04-05 |title=Bruce Eckel's MindView, Inc: Does Java need Checked Exceptions? |publisher=Mindview.net |access-date=2011-12-15 }}</ref>
Early versions of the C++ programming language included an optional mechanism similar to checked exceptions, called '''exception specifications'''. By default any function could throw any exception, but this could be limited by a {{Cpp|throw}} clause added to the function signature, that specified which exceptions the function may throw. Exception specifications were not enforced at compile-time. Violations resulted in the global function {{Cpp|std::unexpected}} being called.<ref name=bjarne-exc>[[Bjarne Stroustrup]], ''[[The C++ Programming Language]]'' Third Edition, [[Addison Wesley]], 1997. {{ISBN|0-201-88954-4}}. pp. 375-380.</ref> An empty exception specification could be given, which indicated that the function will throw no exception. This was not made the default when exception handling was added to the language because it would have required too much modification of existing code, would have impeded interaction with code written in other languages, and would have tempted programmers into writing too many handlers at the local level.<ref name=bjarne-exc/> Explicit use of empty exception specifications could, however, allow C++ compilers to perform significant code and stack layout optimizations that are precluded when exception handling may take place in a function.<ref name=cppeh /> Some analysts viewed the proper use of exception specifications in C++ as difficult to achieve.<ref>{{cite journal | title=Ten Guidelines for Exception Specifications | last=Reeves | first= J.W. | journal=C++ Report | volume=8 | issue=7 |date=July 1996}}</ref> This use of exception specifications was included in [[C++98]] and [[C++03]], [[deprecated]] in the 2012 C++ language standard ([[C++11]]),<ref>{{cite web |url=http://herbsutter.com/2010/03/13/trip-report-march-2010-iso-c-standards-meeting/ |title=Trip Report: March 2010 ISO C++ Standards Meeting |last=Sutter |first=Herb |author-link=Herb Sutter |date=3 March 2010 |access-date=24 March 2010 |url-status=live |archive-url=https://web.archive.org/web/20100323082634/http://herbsutter.com/2010/03/13/trip-report-march-2010-iso-c-standards-meeting/ |archive-date=23 March 2010 }}</ref> and was removed from the language in [[C++17]]. A function that will not throw any exceptions can now be denoted by the {{Cpp|noexcept}} keyword.
| |||