Content deleted Content added
Fgnievinski (talk | contribs) No edit summary |
m clean up, typo(s) fixed: For example → For example, |
||
Line 23:
{{Further|Exception handling syntax}}
Many computer languages have built-in syntactic support for exceptions and exception handling. This includes [[ActionScript]], [[Ada programming language|Ada]], [[BlitzMax]], [[C++]], [[C Sharp (programming language)|C#]], [[Clojure]], [[COBOL]], [[D programming language|D]], [[ECMAScript]], [[Eiffel (programming language)|Eiffel]], [[Java (programming language)|Java]], [[ML programming language|ML]], [[Object Pascal]] (e.g. [[Delphi (programming language)|Delphi]], [[Free Pascal]], and the like), [[PowerBuilder]], [[Objective-C]], [[OCaml]], [[PHP]] (as of version 5), [[PL/I]], [[PL/SQL]], [[Prolog]], [[Python (programming language)|Python]], [[REALbasic]], [[Ruby (programming language)|Ruby]], [[Scala (programming language)|Scala]], [[Seed7]], [[Smalltalk]], [[Tcl]], [[Visual Prolog]] and most [[.NET Framework|.NET]] languages.
Excluding minor syntactic differences, there are only a couple of exception handling styles in use. In the most popular style, an exception is initiated by a special statement (<code>throw</code> or <code>raise</code>) with an exception object (e.g. with Java or Object Pascal) or a value of a special extendable enumerated type (e.g. with Ada or SML). The scope for exception handlers starts with a marker clause (<code>try</code> or the language's block starter such as <code>begin</code>) and ends in the start of the first handler clause (<code>catch</code>, <code>except</code>, <code>rescue</code>). Several handler clauses can follow, and each can specify which exception types it handles and what name it uses for the exception object. As a minor variation, some languages use a single handler clause, which deals with the class of the exception internally.
Line 71:
He backed this statement with experience from several operating systems. The key example was Cedar/Mesa: It was written by people who liked and used resumption, but after ten years of use, there was only one use of resumption left in the half million line system – and that was a context inquiry. Because resumption wasn't actually necessary for such a context inquiry, they removed it and found a significant speed increase in that part of the system. In each and every case where resumption had been used it had – over the ten years – become a problem and a more appropriate design had replaced it. Basically, every use of resumption had represented a failure to keep separate levels of abstraction disjoint.{{sfn|Stroustrup|1994|p=392}}}}
Exception-handling languages with resumption include [[Common Lisp]] with its [[#Condition systems|Condition System]], PL/I, Dylan, [[
== Exception handling implementation ==
Line 150:
</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=347–348 |edition=4th}}</ref> For example, [[C Sharp (programming language)|C#]] does not require or allow declaration of any exception specifications, with the following posted by Eric Gunnerson:<ref>{{cite web |last1=Gunnerson |first1=Eric |title=C# and exception specifications |url=http://discuss.develop.com/archives/wa.exe?A2=ind0011A&L=DOTNET&P=R32820|archive-url=https://web.archive.org/web/20060101083304/http://discuss.develop.com/archives/wa.exe?A2=ind0011A&L=DOTNET&P=R32820 |date=9 November 2000|archive-date=1 January 2006|url-status=dead}}</ref><ref name="Kiniry"/><ref name=Eckel/> {{
[[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 177:
'''Asynchronous exceptions''' are events raised by a separate thread or external process, such as pressing [[Control-C|Ctrl-C]] to interrupt a program, receiving a [[Signal (computing)|signal]], or sending a disruptive message such as "stop" or "suspend" from another [[Thread (computer science)|thread of execution]].<ref>{{cite web |url=http://citeseer.ist.psu.edu/415348.html |title=Asynchronous Exceptions in Haskell - Marlow, Jones, Moran (ResearchIndex) |publisher=Citeseer.ist.psu.edu |access-date=2011-12-15 |url-status=live |archive-url=http://archive.wikiwix.com/cache/20110223164151/http://citeseer.ist.psu.edu/415348.html |archive-date=2011-02-23 }}</ref><ref>{{cite journal|url=http://www.cs.williams.edu/~freund/papers/python.pdf |title=Safe Asynchronous Exceptions For Python |access-date=4 January 2022 |first1=Stephen N.|last1=Freund|first2=Mark P.|last2=Mitchell }}</ref> Whereas synchronous exceptions happen at a specific <code>throw</code> statement, asynchronous exceptions can be raised at any time. It follows that asynchronous exception handling can't be optimized out by the compiler, as it cannot prove the absence of asynchronous exceptions. They are also difficult to program with correctly, as asynchronous exceptions must be blocked during cleanup operations to avoid resource leaks.
Programming languages typically avoid or restrict asynchronous exception handling, for example C++ forbids raising exceptions from signal handlers, and Java has deprecated the use of its ThreadDeath exception that was used to allow one thread to stop another one.<ref>{{cite web |url=http://java.sun.com/j2se/1.5.0/docs/guide/misc/threadPrimitiveDeprecation.html |title=Java Thread Primitive Deprecation |publisher=Java.sun.com |access-date=2011-12-15 |url-status=live |archive-url=https://web.archive.org/web/20090426200153/http://java.sun.com/j2se/1.5.0/docs/guide/misc/threadPrimitiveDeprecation.html |archive-date=2009-04-26 }}</ref> Another feature is a semi-asynchronous mechanism that raises an asynchronous exception only during certain operations of the program. For example, Java's {{C++|Thread.interrupt()}} only affects the thread when the thread calls an operation that throws {{C++|InterruptedException}}.<ref>{{cite web |title=Interrupts (The Java™ Tutorials > Essential Java Classes > Concurrency) |url=https://docs.oracle.com/javase/tutorial/essential/concurrency/interrupt.html |website=docs.oracle.com |access-date=5 January 2022}}</ref> The similar POSIX {{C++|pthread_cancel}} API has race conditions which make it impossible to use safely.<ref>{{cite web |last1=Felker |first1=Rich |title=Thread cancellation and resource leaks |url=http://ewontfix.com/2/ |website=ewontfix.com|access-date=5 January 2022}}</ref>
== Condition systems ==
| |||