Content deleted Content added
Rikivillalba (talk | contribs) |
→Termination and resumption semantics: resumption semantics with termination on exit |
||
Line 110:
When an exception is thrown, the program searches back through the [[call stack|stack]] of function calls until an exception handler is found. Some languages call for [[stack unwinding|unwinding]] the stack as this search progresses. That is, if function {{mono|f}}, containing a handler {{mono|H}} for exception {{mono|E}}, calls function {{mono|g}}, which in turn calls function {{mono|h}}, and an exception {{mono|E}} occurs in {{mono|h}}, then functions {{mono|h}} and {{mono|g}} may be terminated, and {{mono|H}} in {{mono|f}} will handle {{mono|E}}. This is said to be termination semantics.
Alternately, the exception handling mechanisms may not unwind the stack on entry<ref group=note>In, e.g., PL/I, a normal exit from an exception handler unwinds the stack.</ref> to an exception handler, giving the exception handler the option to restart the computation, resume or unwind. This allows the program to continue the computation at exactly the same place where the error occurred (for example when a previously missing file has become available) or to implement notifications, logging, queries and fluid variables on top of the exception handling mechanism (as done in Smalltalk). Allowing the computation to resume where it left off is termed resumption semantics.
There are theoretical and design arguments in favor of either decision. C++ standardization discussions in 1989–1991 resulted in a definitive decision to use termination semantics in C++.{{sfn|Stroustrup|1994|loc=16.6 Exception Handling: Resumption vs. Termination, pp. 390–393}} [[Bjarne Stroustrup]] cites a presentation by [[James G. Mitchell|Jim Mitchell]] as a key data point:
| |||