source: doc/theses/andrew_beach_MMath/features.tex @ bfd7b30

Last change on this file since bfd7b30 was bfd7b30, checked in by Peter A. Buhr <pabuhr@…>, 2 years ago

add virtual type examples and figure

  • Property mode set to 100644
File size: 38.7 KB
1\chapter{Exception Features}
4This chapter covers the design and user interface of the \CFA EHM
5and begins with a general overview of EHMs. It is not a strict
6definition of all EHMs nor an exhaustive list of all possible features.
7However it does cover the most common structure and features found in them.
9\section{Overview of EHMs}
10% We should cover what is an exception handling mechanism and what is an
11% exception before this. Probably in the introduction. Some of this could
12% move there.
13\subsection{Raise / Handle}
14An exception operation has two main parts: raise and handle.
15These terms are sometimes known as throw and catch but this work uses
16throw/catch as a particular kind of raise/handle.
17These are the two parts that the user writes and may
18be the only two pieces of the EHM that have any syntax in a language.
21The raise is the starting point for exception handling
22by raising an exception, which passes it to
23the EHM.
25Some well known examples include the @throw@ statements of \Cpp and Java and
26the \code{Python}{raise} statement of Python. In real systems, a raise may
27perform some other work (such as memory management) but for the
28purposes of this overview that can be ignored.
31The primary purpose of an EHM is to run some user code to handle a raised
32exception. This code is given, with some other information, in a handler.
34A handler has three common features: the previously mentioned user code, a
35region of code it guards, and an exception label/condition that matches
36the raised exception.
37Only raises inside the guarded region and raising exceptions that match the
38label can be handled by a given handler.
39If multiple handlers could can handle an exception,
40EHMs define a rule to pick one, such as ``best match" or ``first found".
42The @try@ statements of \Cpp, Java and Python are common examples. All three
43show the common features of guarded region, raise, matching and handler.
45try {                           // guarded region
46        ...     
47        throw exception;        // raise
48        ...     
49} catch( exception ) {  // matching condition, with exception label
50        ...                             // handler code
55After an exception is raised comes what is usually the biggest step for the
56EHM: finding and setting up the handler for execution. The propagation from raise to
57handler can be broken up into three different tasks: searching for a handler,
58matching against the handler and installing the handler.
61The EHM begins by searching for handlers that might be used to handle
62the exception. The search is restricted to
63handlers that have the raise site in their guarded
65The search includes handlers in the current function, as well as any in
66callers on the stack that have the function call in their guarded region.
69Each handler found is matched with the raised exception. The exception
70label defines a condition that is used with the exception and decides if
71there is a match or not.
72In languages where the first match is used, this step is intertwined with
73searching; a match check is performed immediately after the search finds
74a handler.
77After a handler is chosen, it must be made ready to run.
78The implementation can vary widely to fit with the rest of the
79design of the EHM. The installation step might be trivial or it could be
80the most expensive step in handling an exception. The latter tends to be the
81case when stack unwinding is involved.
83If a matching handler is not guaranteed to be found, the EHM needs a
84different course of action for this case.
85This situation only occurs with unchecked exceptions as checked exceptions
86(such as in Java) are guaranteed to find a matching handler.
87The unhandled action is usually very general, such as aborting the program.
90A common way to organize exceptions is in a hierarchical structure.
91This pattern comes from object-orientated languages where the
92exception hierarchy is a natural extension of the object hierarchy.
94Consider the following exception hierarchy:
98A handler labeled with any given exception can handle exceptions of that
99type or any child type of that exception. The root of the exception hierarchy
100(here \code{C}{exception}) acts as a catch-all, leaf types catch single types,
101and the exceptions in the middle can be used to catch different groups of
102related exceptions.
104This system has some notable advantages, such as multiple levels of grouping,
105the ability for libraries to add new exception types, and the isolation
106between different sub-hierarchies.
107This design is used in \CFA even though it is not a object-orientated
108language; so different tools are used to create the hierarchy.
110% Could I cite the rational for the Python IO exception rework?
113After the handler has finished, the entire exception operation has to complete
114and continue executing somewhere else. This step is usually simple,
115both logically and in its implementation, as the installation of the handler
116is usually set up to do most of the work.
118The EHM can return control to many different places, where
119the most common are after the handler definition (termination)
120and after the raise (resumption).
123For effective exception handling, additional information is often passed
124from the raise to the handler and back again.
125So far, only communication of the exception's identity is covered.
126A common communication method for passing more information is putting fields into the exception instance
127and giving the handler access to them.
128Using reference fields pointing to data at the raise location allows data to be
129passed in both directions.
133Virtual types and casts are not part of \CFA's EHM nor are they required for
134an EHM.
135However, one of the best ways to support an exception hierarchy
136is via a virtual hierarchy and dispatch system.
137Ideally, the virtual system should have been part of \CFA before the work
138on exception handling began, but unfortunately it was not.
139Hence, only the features and framework needed for the EHM were
140designed and implemented for this thesis. Other features were considered to ensure that
141the structure could accommodate other desirable features in the future
142but are not implemented.
143The rest of this section only discusses the implemented subset of the
144virtual-system design.
146The virtual system supports multiple ``trees" of types. Each tree is
147a simple hierarchy with a single root type. Each type in a tree has exactly
148one parent -- except for the root type which has zero parents -- and any
149number of children.
150Any type that belongs to any of these trees is called a virtual type.
151For example, the following hypothetical syntax creates two virtual-type trees.
156vtype V0, V1(V0), V2(V0);
157vtype W0, W1(W0), W2(W1);
164% A type's ancestors are its parent and its parent's ancestors.
165% The root type has no ancestors.
166% A type's descendants are its children and its children's descendants.
167Every virtual type also has a pointer to a virtual table with list of virtual members. Children inherit
168their parent's list of virtual members but may add new members to it.
169For example,
171vtable W0 | { int ?<?( int, int ); int ?+?( int, int ); }
172vtable W1 | { int w, int ?==?( int, int ); int ?-?( int, int ); }
174creates a virtual table for @W0@ initialized with the matching @<@ and @+@
175operations visible at this declaration.  Similarly, @W1@ is initialized with
176@<@ and @+@ from the inheritance with @W0@, plus the @==@ and @-@ operations
177visible at this declaration. It is important to note that these are virtual
178members, not virtual methods of object-orientated programming, and can be of
179any type.
181\PAB{Need to look at these when done.
183\CFA still supports virtual methods as a special case of virtual members.
184Function pointers that take a pointer to the virtual type are modified
185with each level of inheritance so that refers to the new type.
186This means an object can always be passed to a function in its virtual table
187as if it were a method.
188\todo{Clarify (with an example) virtual methods.}
190Each virtual type has a unique id.
191This id and all the virtual members are combined
192into a virtual table type. Each virtual type has a pointer to a virtual table
193as a hidden field.
194\todo{Might need a diagram for virtual structure.}
197Up until this point the virtual system is similar to ones found in
198object-orientated languages but this is where \CFA diverges. Objects encapsulate a
199single set of methods in each type, universally across the entire program,
200and indeed all programs that use that type definition. Even if a type inherits and adds methods, it still encapsulate a
201single set of methods. In this sense,
202object-oriented types are ``closed" and cannot be altered.
204In \CFA, types do not encapsulate any code. Traits are local for each function and
205types can satisfy a local trait, stop satisfying it or, satisfy the same
206trait in a different way at any lexical location in the program where a function is call.
207In this sense, the set of functions/variables that satisfy a trait for a type is ``open" as the set can change at every call site.
208This capability means it is impossible to pick a single set of functions
209that represent a type's implementation across a program.
211\CFA side-steps this issue by not having a single virtual table for each
212type. A user can define virtual tables that are filled in at their
213declaration and given a name. Anywhere that name is visible, even if it is
214defined locally inside a function \PAB{What does this mean? (although that means it does not have a
215static lifetime)}, it can be used.
216Specifically, a virtual type is ``bound" to a virtual table that
217sets the virtual members for that object. The virtual members can be accessed
218through the object.
220While much of the virtual infrastructure is created, it is currently only used
221internally for exception handling. The only user-level feature is the virtual
222cast, which is the same as the \Cpp \code{C++}{dynamic_cast}.
227Note, the syntax and semantics matches a C-cast, rather than the function-like
228\Cpp syntax for special casts. Both the type of @EXPRESSION@ and @TYPE@ must be
229a pointer to a virtual type.
230The cast dynamically checks if the @EXPRESSION@ type is the same or a sub-type
231of @TYPE@, and if true, returns a pointer to the
232@EXPRESSION@ object, otherwise it returns @0p@ (null pointer).
235% Leaving until later, hopefully it can talk about actual syntax instead
236% of my many strange macros. Syntax aside I will also have to talk about the
237% features all exceptions support.
239Exceptions are defined by the trait system; there are a series of traits, and
240if a type satisfies them, then it can be used as an exception. The following
241is the base trait all exceptions need to match.
243trait is_exception(exceptT &, virtualT &) {
244        // Numerous imaginary assertions.
247The trait is defined over two types, the exception type and the virtual table
248type. Each exception type should have a single virtual table type.
249There are no actual assertions in this trait because the trait system
250cannot express them yet (adding such assertions would be part of
251completing the virtual system). The imaginary assertions would probably come
252from a trait defined by the virtual system, and state that the exception type
253is a virtual type, is a descendant of @exception_t@ (the base exception type),
254and note its virtual table type.
256% I did have a note about how it is the programmer's responsibility to make
257% sure the function is implemented correctly. But this is true of every
258% similar system I know of (except Agda's I guess) so I took it out.
260There are two more traits for exceptions defined as follows:
262trait is_termination_exception(
263                exceptT &, virtualT & | is_exception(exceptT, virtualT)) {
264        void defaultTerminationHandler(exceptT &);
267trait is_resumption_exception(
268                exceptT &, virtualT & | is_exception(exceptT, virtualT)) {
269        void defaultResumptionHandler(exceptT &);
272Both traits ensure a pair of types are an exception type, its virtual table
274and defines one of the two default handlers. The default handlers are used
275as fallbacks and are discussed in detail in \vref{s:ExceptionHandling}.
277However, all three of these traits can be tricky to use directly.
278While there is a bit of repetition required,
279the largest issue is that the virtual table type is mangled and not in a user
280facing way. So these three macros are provided to wrap these traits to
281simplify referring to the names:
284All three take one or two arguments. The first argument is the name of the
285exception type. The macro passes its unmangled and mangled form to the trait.
286The second (optional) argument is a parenthesized list of polymorphic
287arguments. This argument is only used with polymorphic exceptions and the
288list is be passed to both types.
289In the current set-up, the two types always have the same polymorphic
290arguments so these macros can be used without losing flexibility.
292For example consider a function that is polymorphic over types that have a
293defined arithmetic exception:
295forall(Num | IS_EXCEPTION(Arithmetic, (Num)))
296void some_math_function(Num & left, Num & right);
299\section{Exception Handling}
301As stated,
302\CFA provides two kinds of exception handling: termination and resumption.
303These twin operations are the core of \CFA's exception handling mechanism.
304This section covers the general patterns shared by the two operations and
305then goes on to cover the details of each individual operation.
307Both operations follow the same set of steps.
308First, a user raises an exception.
309Second, the exception propagates up the stack.
310Third, if a handler is found, the exception is caught and the handler is run.
311After that control continues at a raise-dependent location.
312Fourth, if a handler is not found, a default handler is run and, if it returns, then control
313continues after the raise.
315%This general description covers what the two kinds have in common.
316The differences in the two operations include how propagation is performed, where execution continues
317after an exception is caught and handled, and which default handler is run.
321Termination handling is the familiar EHM and used in most programming
322languages with exception handling.
323It is a dynamic, non-local goto. If the raised exception is matched and
324handled, the stack is unwound and control (usually) continues in the function
325on the call stack that defined the handler.
326Termination is commonly used when an error has occurred and recovery is
327impossible locally.
329% (usually) Control can continue in the current function but then a different
330% control flow construct should be used.
332A termination raise is started with the @throw@ statement:
334throw EXPRESSION;
336The expression must return a reference to a termination exception, where the
337termination exception is any type that satisfies the trait
338@is_termination_exception@ at the call site.
339Through \CFA's trait system, the trait functions are implicitly passed into the
340throw code for use by the EHM.
341A new @defaultTerminationHandler@ can be defined in any scope to
342change the throw's behaviour when a handler is not found (see below).
344The throw copies the provided exception into managed memory to ensure
345the exception is not destroyed if the stack is unwound.
346It is the user's responsibility to ensure the original exception is cleaned
347up whether the stack is unwound or not. Allocating it on the stack is
348usually sufficient.
350% How to say propagation starts, its first sub-step is the search.
351Then propagation starts with the search. \CFA uses a ``first match" rule so
352matching is performed with the copied exception as the search key.
353It starts from the raise in the throwing function and proceeds towards the base of the stack,
354from callee to caller.
355At each stack frame, a check is made for termination handlers defined by the
356@catch@ clauses of a @try@ statement.
358try {
359        GUARDED_BLOCK
360} catch (EXCEPTION_TYPE$\(_1\)$ * [NAME$\(_1\)$]) {
361        HANDLER_BLOCK$\(_1\)$
362} catch (EXCEPTION_TYPE$\(_2\)$ * [NAME$\(_2\)$]) {
363        HANDLER_BLOCK$\(_2\)$
366When viewed on its own, a try statement simply executes the statements
367in the \snake{GUARDED_BLOCK}, and when those are finished,
368the try statement finishes.
370However, while the guarded statements are being executed, including any
371invoked functions, all the handlers in these statements are included in the
372search path.
373Hence, if a termination exception is raised, these handlers may be matched
374against the exception and may handle it.
376Exception matching checks the handler in each catch clause in the order
377they appear, top to bottom. If the representation of the raised exception type
378is the same or a descendant of @EXCEPTION_TYPE@$_i$, then @NAME@$_i$
379(if provided) is
380bound to a pointer to the exception and the statements in @HANDLER_BLOCK@$_i$
381are executed. If control reaches the end of the handler, the exception is
382freed and control continues after the try statement.
384If no termination handler is found during the search, then the default handler
385(\defaultTerminationHandler) visible at the raise statement is called.
386Through \CFA's trait system the best match at the raise statement is used.
387This function is run and is passed the copied exception.
388If the default handler finishes, control continues after the raise statement.
390There is a global @defaultTerminationHandler@ that is polymorphic over all
391termination exception types.
392The global default termination handler performs a cancellation
393(see \vref{s:Cancellation} for the justification) on the current stack with the copied exception.
394Since it is so general, a more specific handler is usually
395defined, possibly with a detailed message, and used for specific exception type, effectively overriding the default handler.
400Resumption exception handling is the less familar EHM, but is
401just as old~\cite{Goodenough75} and is simpler in many ways.
402It is a dynamic, non-local function call. If the raised exception is
403matched, a closure is taken from up the stack and executed,
404after which the raising function continues executing.
405The common uses for resumption exceptions include
406potentially repairable errors, where execution can continue in the same
407function once the error is corrected, and
408ignorable events, such as logging where nothing needs to happen and control
409should always continue from the raise point.
411A resumption raise is started with the @throwResume@ statement:
413throwResume EXPRESSION;
415\todo{Decide on a final set of keywords and use them everywhere.}
416It works much the same way as the termination throw.
417The expression must return a reference to a resumption exception,
418where the resumption exception is any type that satisfies the trait
419@is_resumption_exception@ at the call site.
420The assertions from this trait are available to
421the exception system while handling the exception.
423At run-time, no exception copy is made, since
424resumption does not unwind the stack nor otherwise remove values from the
425current scope, so there is no need to manage memory to keep the exception in scope.
427Then propagation starts with the search. It starts from the raise in the
428resuming function and proceeds towards the base of the stack,
429from callee to caller.
430At each stack frame, a check is made for resumption handlers defined by the
431@catchResume@ clauses of a @try@ statement.
433try {
434        GUARDED_BLOCK
435} catchResume (EXCEPTION_TYPE$\(_1\)$ * [NAME$\(_1\)$]) {
436        HANDLER_BLOCK$\(_1\)$
437} catchResume (EXCEPTION_TYPE$\(_2\)$ * [NAME$\(_2\)$]) {
438        HANDLER_BLOCK$\(_2\)$
441% PAB, you say this above.
442% When a try statement is executed, it simply executes the statements in the
443% @GUARDED_BLOCK@ and then finishes.
445% However, while the guarded statements are being executed, including any
446% invoked functions, all the handlers in these statements are included in the
447% search path.
448% Hence, if a resumption exception is raised, these handlers may be matched
449% against the exception and may handle it.
451% Exception matching checks the handler in each catch clause in the order
452% they appear, top to bottom. If the representation of the raised exception type
453% is the same or a descendant of @EXCEPTION_TYPE@$_i$, then @NAME@$_i$
454% (if provided) is bound to a pointer to the exception and the statements in
455% @HANDLER_BLOCK@$_i$ are executed.
456% If control reaches the end of the handler, execution continues after the
457% the raise statement that raised the handled exception.
459% Like termination, if no resumption handler is found during the search,
460% then the default handler (\defaultResumptionHandler) visible at the raise
461% statement is called. It will use the best match at the raise sight according
462% to \CFA's overloading rules. The default handler is
463% passed the exception given to the raise. When the default handler finishes
464% execution continues after the raise statement.
466% There is a global @defaultResumptionHandler{} is polymorphic over all
467% resumption exceptions and performs a termination throw on the exception.
468% The \defaultTerminationHandler{} can be overridden by providing a new
469% function that is a better match.
471The @GUARDED_BLOCK@ and its associated nested guarded statements work the same
472for resumption as for termination, as does exception matching at each
473@catchResume@. Similarly, if no resumption handler is found during the search,
474then the currently visible default handler (\defaultResumptionHandler) is
475called and control continues after the raise statement if it returns. Finally,
476there is also a global @defaultResumptionHandler@, which can be overridden,
477that is polymorphic over all resumption exceptions but performs a termination
478throw on the exception rather than a cancellation.
480Throwing the exception in @defaultResumptionHandler@ has the positive effect of
481walking the stack a second time for a recovery handler. Hence, a programmer has
482two chances for help with a problem, fixup or recovery, should either kind of
483handler appear on the stack. However, this dual stack walk leads to following
484apparent anomaly:
486try {
487        throwResume E;
488} catch (E) {
489        // this handler runs
492because the @catch@ appears to handle a @throwResume@, but a @throwResume@ only
493matches with @catchResume@. The anomaly results because the unmatched
494@catchResuem@, calls @defaultResumptionHandler@, which in turn throws @E@.
496% I wonder if there would be some good central place for this.
497Note, termination and resumption handlers may be used together
498in a single try statement, intermixing @catch@ and @catchResume@ freely.
499Each type of handler only interacts with exceptions from the matching
500kind of raise.
502\subsubsection{Resumption Marking}
504A key difference between resumption and termination is that resumption does
505not unwind the stack. A side effect is that, when a handler is matched
506and run, its try block (the guarded statements) and every try statement
507searched before it are still on the stack. There presence can lead to
508the \emph{recursive resumption problem}.
510The recursive resumption problem is any situation where a resumption handler
511ends up being called while it is running.
512Consider a trivial case:
514try {
515        throwResume (E &){};
516} catchResume(E *) {
517        throwResume (E &){};
520When this code is executed, the guarded @throwResume@ starts a
521search and matches the handler in the @catchResume@ clause. This
522call is placed on the stack above the try-block. Now the second raise in the handler
523searches the same try block, matches, and puts another instance of the
524same handler on the stack leading to infinite recursion.
526While this situation is trivial and easy to avoid, much more complex cycles can
527form with multiple handlers and different exception types.  The key point is
528that the programmer's intuition expects every raise in a handler to start
529searching \emph{below} the @try@ statement, making it difficult to understand
530and fix the problem.
532To prevent all of these cases, each try statement is ``marked" from the
533time the exception search reaches it to either when a matching handler
534completes or when the search reaches the base
535of the stack.
536While a try statement is marked, its handlers are never matched, effectively
537skipping over it to the next try statement.
543There are other sets of marking rules that could be used,
544for instance, marking just the handlers that caught the exception,
545would also prevent recursive resumption.
546However, the rule selected mirrors what happens with termination,
547and hence, matches programmer intuition that a raise searches below a try.
549In detail, the marked try statements are the ones that would be removed from
550the stack for a termination exception, \ie those on the stack
551between the handler and the raise statement.
552This symmetry applies to the default handler as well, as both kinds of
553default handlers are run at the raise statement, rather than (physically
554or logically) at the bottom of the stack.
555% In early development having the default handler happen after
556% unmarking was just more useful. We assume that will continue.
558\section{Conditional Catch}
559Both termination and resumption handler clauses can be given an additional
560condition to further control which exceptions they handle:
564First, the same semantics is used to match the exception type. Second, if the
565exception matches, @CONDITION@ is executed. The condition expression may
566reference all names in scope at the beginning of the try block and @NAME@
567introduced in the handler clause. If the condition is true, then the handler
568matches. Otherwise, the exception search continues as if the exception type
569did not match.
571The condition matching allows finer matching by checking
572more kinds of information than just the exception type.
574try {
575        handle1 = open( f1, ... );
576        handle2 = open( f2, ... );
577        handle3 = open( f3, ... );
578        ...
579} catch( IOFailure * f ; fd( f ) == f1 ) {
580        // Only handle IO failure for f1.
581} catch( IOFailure * f ; fd( f ) == f3 ) {
582        // Only handle IO failure for f3.
584// Handle a failure relating to f2 further down the stack.
586In this example the file that experienced the IO error is used to decide
587which handler should be run, if any at all.
590% I know I actually haven't got rid of them yet, but I'm going to try
591% to write it as if I had and see if that makes sense:
594Within the handler block or functions called from the handler block, it is
595possible to reraise the most recently caught exception with @throw@ or
596@throwResume@, respectively.
598try {
599        ...
600} catch( ... ) {
601        ... throw;
602} catchResume( ... ) {
603        ... throwResume;
606The only difference between a raise and a reraise is that reraise does not
607create a new exception; instead it continues using the current exception, \ie
608no allocation and copy. However the default handler is still set to the one
609visible at the raise point, and hence, for termination could refer to data that
610is part of an unwound stack frame. To prevent this problem, a new default
611handler is generated that does a program-level abort.
614\subsection{Comparison with Reraising}
615Without conditional catch, the only approach to match in more detail is to reraise
616the exception after it has been caught, if it could not be handled.
620try {
621        do_work_may_throw();
622} catch(excep_t * ex; can_handle(ex)) {
624        handle(ex);
632try {
633        do_work_may_throw();
634} catch(excep_t * ex) {
635        if (can_handle(ex)) {
636                handle(ex);
637        } else {
638                throw;
639        }
644Notice catch-and-reraise increases complexity by adding additional data and
645code to the exception process. Nevertheless, catch-and-reraise can simulate
646conditional catch straightforwardly, when exceptions are disjoint, \ie no
649However, catch-and-reraise simulation becomes unusable for exception inheritance.
652exception E1;
653exception E2(E1); // inheritance
657try {
658        ... foo(); ... // raise E1/E2
659        ... bar(); ... // raise E1/E2
660} catch( E2 e; e.rtn == foo ) {
661        ...
662} catch( E1 e; e.rtn == foo ) {
663        ...
664} catch( E1 e; e.rtn == bar ) {
665        ...
671try {
672        ... foo(); ...
673        ... bar(); ...
674} catch( E2 e ) {
675        if ( e.rtn == foo ) { ...
676        } else throw; // reraise
677} catch( E1 e ) {
678        if (e.rtn == foo) { ...
679        } else if (e.rtn == bar) { ...
680        else throw; // reraise
685The derived exception @E2@ must be ordered first in the catch list, otherwise
686the base exception @E1@ catches both exceptions. In the catch-and-reraise code
687(right), the @E2@ handler catches exceptions from both @foo@ and
688@bar@. However, the reraise misses the following catch clause. To fix this
689problem, an enclosing @try@ statement is need to catch @E2@ for @bar@ from the
690reraise, and its handler must duplicate the inner handler code for @bar@. To
691generalize, this fix for any amount of inheritance and complexity of try
692statement requires a technique called \emph{try-block
693splitting}~\cite{Krischer02}, which is not discussed in this thesis. It is
694sufficient to state that conditional catch is more expressive than
695catch-and-reraise in terms of complexity.
698That is, they have the same behaviour in isolation.
699Two things can expose differences between these cases.
701One is the existence of multiple handlers on a single try statement.
702A reraise skips all later handlers for a try statement but a conditional
703catch does not.
704% Hence, if an earlier handler contains a reraise later handlers are
705% implicitly skipped, with a conditional catch they are not.
706Still, they are equivalently powerful,
707both can be used two mimic the behaviour of the other,
708as reraise can pack arbitrary code in the handler and conditional catches
709can put arbitrary code in the predicate.
710% I was struggling with a long explanation about some simple solutions,
711% like repeating a condition on later handlers, and the general solution of
712% merging everything together. I don't think it is useful though unless its
713% for a proof.
716The question then becomes ``Which is a better default?"
717We believe that not skipping possibly useful handlers is a better default.
718If a handler can handle an exception it should and if the handler can not
719handle the exception then it is probably safer to have that explicitly
720described in the handler itself instead of implicitly described by its
721ordering with other handlers.
722% Or you could just alter the semantics of the throw statement. The handler
723% index is in the exception so you could use it to know where to start
724% searching from in the current try statement.
725% No place for the `goto else;` metaphor.
727The other issue is all of the discussion above assumes that the only
728way to tell apart two raises is the exception being raised and the remaining
729search path.
730This is not true generally, the current state of the stack can matter in
731a number of cases, even only for a stack trace after an program abort.
732But \CFA has a much more significant need of the rest of the stack, the
733default handlers for both termination and resumption.
735% For resumption it turns out it is possible continue a raise after the
736% exception has been caught, as if it hadn't been caught in the first place.
737This becomes a problem combined with the stack unwinding used in termination
738exception handling.
739The stack is unwound before the handler is installed, and hence before any
740reraises can run. So if a reraise happens the previous stack is gone,
741the place on the stack where the default handler was supposed to run is gone,
742if the default handler was a local function it may have been unwound too.
743There is no reasonable way to restore that information, so the reraise has
744to be considered as a new raise.
745This is the strongest advantage conditional catches have over reraising,
746they happen before stack unwinding and avoid this problem.
748% The one possible disadvantage of conditional catch is that it runs user
749% code during the exception search. While this is a new place that user code
750% can be run destructors and finally clauses are already run during the stack
751% unwinding.
754%   `exception_ptr current_exception() noexcept;`
758\section{Finally Clauses}
760Finally clauses are used to preform unconditional clean-up when leaving a
761scope and are placed at the end of a try statement after any handler clauses:
763try {
764        GUARDED_BLOCK
765} ... // any number or kind of handler clauses
766... finally {
767        FINALLY_BLOCK
770The @FINALLY_BLOCK@ is executed when the try statement is removed from the
771stack, including when the @GUARDED_BLOCK@ finishes, any termination handler
772finishes, or during an unwind.
773The only time the block is not executed is if the program is exited before
774the stack is unwound.
776Execution of the finally block should always finish, meaning control runs off
777the end of the block. This requirement ensures control always continues as if
778the finally clause is not present, \ie finally is for cleanup not changing
779control flow.
780Because of this requirement, local control flow out of the finally block
781is forbidden. The compiler precludes any @break@, @continue@, @fallthru@ or
782@return@ that causes control to leave the finally block. Other ways to leave
783the finally block, such as a long jump or termination are much harder to check,
784and at best requiring additional run-time overhead, and so are only
787Not all languages with unwinding have finally clauses. Notably \Cpp does
788without it as destructors, and the RAII design pattern, serve a similar role.
789Although destructors and finally clauses can be used for the same cases,
790they have their own strengths, similar to top-level function and lambda
791functions with closures.
792Destructors take more work for their creation, but if there is clean-up code
793that needs to be run every time a type is used, they are much easier
794to set-up.
795On the other hand finally clauses capture the local context, so is easy to
796use when the clean-up is not dependent on the type of a variable or requires
797information from multiple variables.
801Cancellation is a stack-level abort, which can be thought of as as an
802uncatchable termination. It unwinds the entire current stack, and if
803possible forwards the cancellation exception to a different stack.
805Cancellation is not an exception operation like termination or resumption.
806There is no special statement for starting a cancellation; instead the standard
807library function @cancel_stack@ is called passing an exception. Unlike a
808raise, this exception is not used in matching only to pass information about
809the cause of the cancellation.
810Finaly, since a cancellation only unwinds and forwards, there is no default handler.
812After @cancel_stack@ is called the exception is copied into the EHM's memory
813and the current stack is unwound.
814The behaviour after that depends on the kind of stack being cancelled.
816\paragraph{Main Stack}
817The main stack is the one used by the program main at the start of execution,
818and is the only stack in a sequential program.
819After the main stack is unwound there is a program-level abort.
821The reasons for this semantics in a sequential program is that there is no more code to execute.
822This semantics also applies to concurrent programs, too, even if threads are running.
823That is, if any threads starts a cancellation, it implies all threads terminate.
824Keeping the same behaviour in sequential and concurrent programs is simple.
825Also, even in concurrent programs there may not currently be any other stacks
826and even if other stacks do exist, main has no way to know where they are.
828\paragraph{Thread Stack}
829A thread stack is created for a \CFA @thread@ object or object that satisfies
830the @is_thread@ trait.
831After a thread stack is unwound, the exception is stored until another
832thread attempts to join with it. Then the exception @ThreadCancelled@,
833which stores a reference to the thread and to the exception passed to the
834cancellation, is reported from the join to the joining thread.
835There is one difference between an explicit join (with the @join@ function)
836and an implicit join (from a destructor call). The explicit join takes the
837default handler (@defaultResumptionHandler@) from its calling context while
838the implicit join provides its own; which does a program abort if the
839@ThreadCancelled@ exception cannot be handled.
841The communication and synchronization are done here because threads only have
842two structural points (not dependent on user-code) where
843communication/synchronization happens: start and join.
844Since a thread must be running to perform a cancellation (and cannot be
845cancelled from another stack), the cancellation must be after start and
846before the join, so join is used.
848% TODO: Find somewhere to discuss unwind collisions.
849The difference between the explicit and implicit join is for safety and
850debugging. It helps prevent unwinding collisions by avoiding throwing from
851a destructor and prevents cascading the error across multiple threads if
852the user is not equipped to deal with it.
853It is always possible to add an explicit join if that is the desired behaviour.
855With explicit join and a default handler that triggers a cancellation, it is
856possible to cascade an error across any number of threads, cleaning up each
857in turn, until the error is handled or the main thread is reached.
859\paragraph{Coroutine Stack}
860A coroutine stack is created for a @coroutine@ object or object that
861satisfies the @is_coroutine@ trait.
862After a coroutine stack is unwound, control returns to the @resume@ function
863that most recently resumed it. @resume@ reports a
864@CoroutineCancelled@ exception, which contains a references to the cancelled
865coroutine and the exception used to cancel it.
866The @resume@ function also takes the \defaultResumptionHandler{} from the
867caller's context and passes it to the internal report.
869A coroutine only knows of two other coroutines, its starter and its last resumer.
870The starter has a much more distant connection, while the last resumer just
871(in terms of coroutine state) called resume on this coroutine, so the message
872is passed to the latter.
874With a default handler that triggers a cancellation, it is possible to
875cascade an error across any number of coroutines, cleaning up each in turn,
876until the error is handled or a thread stack is reached.
878\PAB{Part of this I do not understand. A cancellation cannot be caught. But you
879talk about handling a cancellation in the last sentence. Which is correct?}
Note: See TracBrowser for help on using the repository browser.