source: doc/theses/andrew_beach_MMath/features.tex@ 857a1c6

\chapter{Exception Features}

This chapter covers the design and user interface of the \CFA
exception-handling mechanism (EHM). % or exception system.
While an EHM is free to add many features,
the following overview covers the basic features that all EHMs use, but it is not an
exhaustive list of everything an EHM can do.

% We should cover what is an exception handling mechanism and what is an
% exception before this. Probably in the introduction. Some of this could
% move there.
\paragraph{Raise / Handle}
An exception operation has two main parts: raise and handle.
These terms are sometimes also known as throw and catch but this work uses
throw/catch as a particular kind of raise/handle.
These are the two parts a programmer writes and so
are the only two pieces of the EHM that have language syntax.

\subparagraph{Raise}
The raise is the starting point for exception handling and usually how \PAB{This sentence is cut off.}
Some well known examples include the @throw@ statement of \Cpp and Java and
the \lstinline[language=Python]{raise} statement from Python.

For this overview, a raise starts the handling of an
exception, which is called \newterm{raising} an exception. This simple description is sufficient
for the overview.

\subparagraph{Handle}
The purpose of raising an exception is to run user code to address (handle) the
issue found at the raise point.
The @try@ statement of \Cpp illustrates a common approach for specifying multiple handlers.
A handler has three common features: the scope in which it applies, an
exception label that describes what exceptions it can handle, and code to run
that deals with the raised issue.
Each handler can handle exceptions raised in the region matching its
exception label. For multiple matches, different EHMs have different rules for matching an exception to a handler label,
such as ``best match" or ``first found".

\paragraph{Propagation}
After an exception is raised, comes the most complex step for the
EHM: finding and setting up the handler. This propagation of exception from raise to handler can be broken up into three
different tasks: searching, matching, and
installing the handler so it can execute.

\subparagraph{Searching}
The EHM searches for possible handlers that can be used to handle
the exception. Searching is usually independent of the exception that is
thrown and instead depends on the call stack: current function, its caller
and repeating down the stack.

\subparagraph{Matching}
For each handler found, it compares the raised exception with the handler label to see which one is the
best match, and hence, which one should be used to handle the exception.
In languages where the best match is the first match, these two steps are often
intertwined, \ie a match check is performed immediately after the search finds
a possible handler.

\subparagraph{Installing}
After a handler is chosen, it must be made ready to run.
This step varies widely to fit with the rest of the
design of the EHM. The installation step might be trivial or it can be
the most expensive step in handling an exception. The latter tends to be the
case when stack unwinding is involved.
An alternate action occurs if no appropriate handler is found, then some implicit action
is performed. This step is only required with unchecked
exceptions as checked exceptions (Java) promise a handler is always found. The implicit action
also installs a handler but it is a default handle that may be
installed differently.

\subparagraph{Hierarchy}
Some EHM (\CFA, Java) organize exceptions in a hierarchical structure.
This strategy is borrowed from object-orientated languages where the
exception hierarchy is a natural extension of the object hierarchy.

Consider the following hierarchy of exceptions:
\begin{center}
\input{exceptionHierarchy}
\end{center}
A handler labelled with any given exception can handle exceptions of that
type or any child type of that exception. The root of the exception hierarchy
(here \lstinline[language=C++]{exception}) acts as a catch-all, leaf types catch single types
and the exceptions in the middle can be used to catch different groups of
related exceptions.

This system has some notable advantages, such as multiple levels of grouping,
the ability for libraries to add new exception types, and the isolation
between different sub-hierarchies. This capability had to be adapted for \CFA, which is a
non-object-orientated language.

% Could I cite the rational for the Python IO exception rework?

\paragraph{Completion}
After the handler has returned, the entire exception operation has to complete
and continue executing somewhere. This step is usually simple,
both logically and in its implementation, as the installation of the handler
usually does the preparation.
The EHM can return control to different places,
where the most common are after the handler definition or after the raise.

\paragraph{Communication}
For effective exception handling, additional information is usually passed from the raise,
where this basic model only communicates the exception's identity. A common
methods for communication is putting fields into an exception and
allowing a handler to access these fields via an exception instance in the handler's scope.

\section{Virtuals}
Virtual types and casts are not part of an EHM nor are they
required for an EHM. But as pointed out, an object-oriented-style hierarchy is an
excellent way of organizing exceptions. Hence, a minimal virtual system has been added
to \CFA to support hierarchical exceptions.

The virtual system supports multiple ``trees" of types. Each tree is
a simple hierarchy with a single root type. Each type in a tree has exactly
one parent -- except for the root type with zero parents -- and any
number of children.
Any type that belongs to any of these trees is called a virtual type.

% A type's ancestors are its parent and its parent's ancestors.
% The root type has no ancestors.
% A type's descendents are its children and its children's descendents.

Every virtual type has a list of virtual members. Children inherit
their parent's virtual members but may add new members to it.
It is important to note that these are virtual members, not virtual methods of an object type.
However, as \CFA has function pointers, they can be used to mimic virtual
methods.

Each virtual type has a unique id.
The unique id for the virtual type and all its virtual members are combined
into a virtual-table type. Each virtual type has a pointer to a virtual table
as a hidden field.

Up to this point, a virtual system is similar to ones found in object-oriented
languages but this is where \CFA diverges. Objects encapsulate a
single set of behaviours in each type, universally across the entire program,
and indeed all programs that use that type definition. In this sense, the
types are ``closed" and cannot be altered.
However, \CFA types do not encapsulate any behaviour. Instead, traits are used and
types can satisfy a trait, stop satisfying a trait, or satisfy the same
trait in a different way depending on the lexical context. In this sense, the types are
``open" as their behaviour can change in different scopes. This capability means it is impossible to pick
a single set of functions that represent the type's virtual members.

Hence, \CFA does not have a single virtual table for a type. A user can define different virtual tables,
which are filled in at their declaration and given a name. 
That name is used as the virtual table, even if it is defined locally
inside a function, although lifetime issues must be considered.
Specifically, an object of a virtual type is ``bound" to a virtual table instance, which
sets the virtual members for that object. The virtual members can be accessed
through the object.

While much of the virtual infrastructure is created, it is currently only used
internally for exception handling. The only user-level feature is the virtual
cast, which is the same as the \Cpp \lstinline[language=C++]|dynamic_cast|.
\label{p:VirtualCast}
\begin{cfa}
(virtual TYPE)EXPRESSION
\end{cfa}
Note, the syntax and semantics matches a C-cast, rather than the function-like
\Cpp syntax for special casts. Both the type of @EXPRESSION@ and @TYPE@ must be
a pointer to a virtual type.
The cast dynamically checks if the @EXPRESSION@ type is the same or a subtype
of @TYPE@, and if true, returns a pointer to the
@EXPRESSION@ object, otherwise it returns @0p@ (null pointer).

\section{Exception}
% Leaving until later, hopefully it can talk about actual syntax instead
% of my many strange macros. Syntax aside I will also have to talk about the
% features all exceptions support.

Exceptions are defined by the trait system; there are a series of traits, and
if a type satisfies them, then it can be used as an exception. The following
is the base trait all exceptions need to match.
\begin{cfa}
trait is_exception(exceptT &, virtualT &) {
        virtualT const & get_exception_vtable(exceptT *);
};
\end{cfa}
The trait is defined over two types, the exception type and the virtual table
type. These type should have a one-to-one relationship: each exception type has only one virtual
table type and vice versa. The only assertion in the trait is
@get_exception_vtable@, which takes a pointer of the exception type and
returns a reference to the virtual-table type-instance.

The function @get_exception_vtable@ is actually a constant function.
Regardless of the value passed in (including the null pointer) it
returns a reference to the virtual-table instance for that type.
The reason it is a function instead of a constant is to make type
annotations easier to write using the exception type rather than the
virtual-table type, which usually has a mangled name because it is an internal component of the EHM.
% Also \CFA's trait system handles functions better than constants and doing
% it this way reduce the amount of boiler plate we need.

% I did have a note about how it is the programmer's responsibility to make
% sure the function is implemented correctly. But this is true of every
% similar system I know of (except Ada's I guess) so I took it out.

There are two more exception traits defined as follows:
\begin{cfa}
trait is_termination_exception(
                exceptT &, virtualT & | is_exception(exceptT, virtualT)) {
        void defaultTerminationHandler(exceptT &);
};

trait is_resumption_exception(
                exceptT &, virtualT & | is_exception(exceptT, virtualT)) {
        void defaultResumptionHandler(exceptT &);
};
\end{cfa}
These traits ensure a given type and virtual type are an
exception type and defines one of the two default handlers. The default handlers
are used in the main exception-handling operations and discussed in detail in \VRef{s:ExceptionHandling}.

However, all three of these traits are tricky to use directly.
While there is a bit of repetition required,
the largest issue is that the virtual-table type is mangled and not in a user
facing way. So three macros are provided to wrap these traits
to simplify referring to the names:
@IS_EXCEPTION@, @IS_TERMINATION_EXCEPTION@ and @IS_RESUMPTION_EXCEPTION@.

These macros take one or two arguments. The first argument is the name of the
exception type. The macro passes the unmangled and mangled form to the trait.
The second (optional) argument is a parenthesized list of polymorphic
arguments. This argument is only used with polymorphic exceptions and the
list is passed to both types.
In the current set-up, the base name and the polymorphic arguments have to
match so these macros can be used without losing flexibility.

For example consider a function that is polymorphic over types that have a
defined arithmetic exception:
\begin{cfa}
forall(Num | @IS_EXCEPTION(Arithmetic, Num)@)
void some_math_function(Num & left, Num & right);
\end{cfa}
where the function may raise exception @Arithmetic@ or any of its decedents.

\section{Exception Handling}
\label{s:ExceptionHandling}
\CFA provides two kinds of exception handling: termination and resumption.
These twin mechanisms are the core of the \CFA EHM and
multiple features are provided to support them.
This section covers the general patterns shared by the two kinds of exceptions and
then covers the individual detail operations.

Both mechanisms follow the same set of steps to do their operations. Both
start with the user performing an exception raise.
Then there is the handler search. If one is found, than the exception
is caught and the handler is run. When the handler returns, control returns to an
location appropriate for each kind of exception.

\begin{sloppypar}
If the search fails, an appropriate default handler, @defaultTermiationHandler@
or @defaultResumptionHandler@, is run and  control returns to the
appropriate location.
\end{sloppypar}

\subsection{Termination}
\label{s:Termination}
Termination handling is familiar and used in most programming
languages with exception handling.
It is a dynamic, non-local goto. The raise starts searching, and if matched and handled, the stack is
unwound and control (usually) continues in the function on
the call stack containing the handler. Terminate is commonly used for an error where recovery
is impossible in the function performing the raise.

% (usually) Control can continue in the current function but then a different
% control flow construct should be used.

A termination raise is started with the @throw@ statement:
\begin{cfa}
throw EXPRESSION;
\end{cfa}
The expression must return a reference to a termination exception, where the
termination exception is any type that satisfies trait
@is_termination_exception@ at the call site.  Through \CFA's trait system, the
trait functions are implicitly passed into the hidden throw code and available
to the exception system while handling the exception. A new
@defaultTerminationHandler@ can be defined in any scope to change the throw's
unhandled behaviour (see below).

The throw must copy the provided exception into managed memory because the stack is unwounded.
The lifetime of the exception copy is managed by the exception runtime.
It is the user's responsibility to ensure the original exception is cleaned up, where allocating it on the unwound stack is sufficient.

The exception search walks the stack matching with the copied exception.
It starts from the throwing function and proceeds to the base of the stack,
from callee to caller.
At each stack frame, a check is made for termination handlers defined by the
@catch@ clauses of a @try@ statement.
\begin{cfa}
try {
        GUARDED_BLOCK
} catch (EXCEPTION_TYPE$\(_1\)$ [* NAME$\(_1\)$]) {
        HANDLER_BLOCK$\(_1\)$
} catch (EXCEPTION_TYPE$\(_2\)$ [* NAME$\(_2\)$]) {
        HANDLER_BLOCK$\(_2\)$
}
\end{cfa}
When viewed on its own, a @try@ statement with @catch@ clauses simply executes the statements in
the @GUARDED_BLOCK@, and when those are finished, the try statement finishes.

However, while the guarded statements are being executed, including any invoked
functions, a termination exception may be thrown. If that exception is not handled by a try
statement further up the stack, the handlers following the try block are now
searched for a matching termination exception-type from top to bottom.

Exception matching checks each @catch@ clasue from top to bottom, if the representation of the thrown exception-type is
the same or a descendant type of the exception types in the @catch@ clauses. If
it is the same or a descendant of @EXCEPTION_TYPE@$_i$, then the optional @NAME@$_i$ is
bound to a pointer to the exception and the statements in @HANDLER_BLOCK@$_i$
are executed. If control reaches the end of the handler, the exception is
freed and control continues after the @try@ statement.

If no termination handler is found during the search, the default termination
handler visible at the raise is called.  Through \CFA's trait-system the best
default-handler match at the throw sight is used.  This function is
passed the copied exception given to the raise. After the default handler is
run, control continues after the @throw@ statement.

There is a global @defaultTerminationHandler@ function that that is polymorphic
over all exception types allowing new default handlers to be defined for
different exception types and so different exception types can have different
default handlers.  The global default termination-handler performs a
cancellation \see{\VRef{s:Cancellation}} on the current stack with the copied
exception.

\subsection{Resumption}
\label{s:Resumption}
Resumption exception-handling is a less common counterpart to termination but is
just as old~\cite{Goodenough75} and is simpler to understand.
It is a dynamic, non-local function call (like Lisp). If the throw is successful, a
closure is taken from up the stack and executed, after which the throwing
function continues executing.
Resumption is used when an error occurred, and if the error is repaired,
then the function can continue.

An alternative approach is explicitly passing fixup functions with local
closures up the stack to be called when an error occurs. However, fixup
functions significantly expand the parameters list of functions, even when the
fixup function is not used by a function but must be passed to other called
functions.

A resumption raise is started with the @throwResume@ statement:
\begin{cfa}
throwResume EXPRESSION;
\end{cfa}
Like termination, the expression must return a reference to a resumption
exception, where the resumption exception is any type that satisfies the trait
@is_termination_exception@ at the call site.
The assertions for this trait are available to
the exception system while handling the exception.

At runtime, no exception copy is made, as the stack is not unwound. Hence, the exception and
any values on the stack remain in scope while the resumption is handled.

The exception searches walks the stack matching with the provided exception.
It starts from the resuming function and proceeds to the base of the stack,
from callee to caller.
At each stack frame, a check is made for resumption handlers defined by the
@catchResume@ clauses of a @try@ statement.
\begin{cfa}
try {
        GUARDED_BLOCK
} catchResume (EXCEPTION_TYPE$\(_1\)$ [* NAME$\(_1\)$]) {
        HANDLER_BLOCK$\(_1\)$
} catchResume (EXCEPTION_TYPE$\(_2\)$ [* NAME$\(_2\)$]) {
        HANDLER_BLOCK$\(_2\)$
}
\end{cfa}
Termination and resumption handlers may be intermixed in a @try@
statement but the kind of throw must match with kind of handler for it to be
considered as a possible match.
Like termination, when viewed on its own, a @try@ statement with
@catchResume@ clauses simply executes the statements in the @GUARDED_BLOCK@,
and when those are finished, the try statement finishes.

However, while the guarded statements are being executed, including any invoked
functions, a resumption exception may be thrown. If that exception is not handled by a try
statement further up the stack, the handlers following the try block are now
searched for a matching resumption exception-type from top to bottom.

Like termination, exception matching checks each @catch@ clasue from top to bottom, if the representation of the thrown exception-type is
the same or a descendant type of the exception types in the @catchResume@ clauses. If
it is the same or a descendant of @EXCEPTION_TYPE@$_i$, then the optional @NAME@$_i$ is
bound to a pointer to the exception and the statements in @HANDLER_BLOCK@$_i$
are executed. If control reaches the end of the handler, the exception is
freed and control continues after the @throwResume@ statement.

Like termination, if no resumption handler is found during the search, the
default resumption handler visible at the raise is called, which is the best
match at the according to \CFA's overloading rules. This function is passed the
exception given to the raise. After the default handler is run, execution
continues after the @throwResume@ statement.

There is a global @defaultResumptionHandler@ that is polymorphic over all
resumption and preforms a termination throw on the exception.
The @defaultTerminationHandler@ for that throw is matched at the original
throw statement (the resumption @throwResume@) and it can be customized by
introducing a new or better match as well.

\subsection{Resumption Marking}
A key difference between resumption and termination is that resumption does
not unwind the stack. A side effect is that when a handler is matched
and run its try block (the guarded statements) and every try statement
searched before it are still on the stack. This can lead to the recursive
resumption problem.

The recursive resumption problem is any situation where a resumption handler
ends up being called while it is running.
Consider a trivial case:
\begin{cfa}
try {
        throwResume (E &){};
} catchResume(E *) {
        throwResume (E &){};
}
\end{cfa}
When this code is executed the guarded @throwResume@ starts a
search and matches the handler in the @catchResume@ clause. The handler is
called and placed on the stack on top of the try-block. The second throw in the handler
searches the same try block and calls another instance of the
same handler leading to an infinite loop.

While this situation is trivial and easy to avoid, much more complex cycles
can form with multiple handlers and different exception types.

To prevent this case, examined try statements on the stack are marked, so that
subsequent resumption searches skip over them and continue with the next unmarked section
of the stack.
Unmarking occurs when that exception is handled
or the search completes without finding a handler.

% This might need a diagram. But it is an important part of the justification
% of the design of the traversal order.

\begin{center}
%\begin{verbatim}
%       throwResume2 ----------.
%            |                 |
% generated from handler       |
%            |                 |
%         handler              |
%            |                 |
%        throwResume1 -----.   :
%            |             |   :
%           try            |   : search skip
%            |             |   :
%        catchResume  <----'   :
%            |                 |
%\end{verbatim}
\input{stackMarking}
\end{center}

The resulting search can be understood by thinking about what is searched for
termination. When a throw happens in a handler, a termination handler
skips everything from the original throw to the original catch because that
part of the stack is unwound. A resumption handler skips the same
section of stack because it is marked.
A throw in a resumption default-handler performs the same search as the original
@throwResume@ because for resumption nothing has been unwound.

The symmetry between resumption masking and termination searching is why this pattern was picked. Other patterns,
such as marking just the handlers that caught, also work but the
symmetry seems to match programmer intuition.

\section{Conditional Catch}
Both termination and resumption handler-clauses can be given an additional
condition to further control which exceptions is handled:
\begin{cfa}
catch (EXCEPTION_TYPE [* NAME] @; CONDITION@)
\end{cfa}
First, the same semantics is used to match the exception type. Second, if the
exception matches, @CONDITION@ is executed. The condition expression may
reference all names in the scope of the try block and @NAME@
introduced in the handler clause. If the condition is true, then the handler
matches. Otherwise, the exception search continues as if the exception type
did not match.

Conditional catch allows fine-gain matching based on object values as well as exception types.
For example, assume the exception hierarchy @OpenFailure@ $\rightarrow$ @CreateFailure@ and these exceptions are raised by function @open@.
\begin{cfa}
try {
        f1 = open( ... ); // open raises CreateFailure/OpenFailure
        f2 = open( ... ); //    with the associate file
        ...
} catch( CreateFailure * f ; @fd( f ) == f1@ ) {
        // only handle IO failure for f1
} catch( OpenFailure * f ; @fd( f ) == f2@ ) {
        // only handle IO failure for f2
}
\end{cfa}
Here, matching is very precise on the I/O exception and particular file with an open problem.
This capability cannot be easily mimiced within the handler.
\begin{cfa}
try {
        f1 = open( ... );
        f2 = open( ... );
        ...
} catch( CreateFailure * f ) {
        if ( @fd( f ) == f1@ ) ... else // reraise 
} catch( OpenFailure * f ) {
        if ( @fd( f ) == f2@ ) ... else // reraise 
}
\end{cfa}
When an exception @CreateFailure@ is raised, the first handler catches the
derived exception and reraises it if the object is inappropriate. The reraise
immediately terminates the current guarded block, which precludes the handler
for the base exception @OpenFailure@ from consideration for object
@f2@. Therefore, the ``catch first, then reraise'' approach is an incomplete
substitute for conditional catch.

\section{Reraise}
\label{s:Rethrowing}
\colour{red}{From Andrew: I recommend we talk about why the language doesn't
have rethrows/reraises instead.}

Within the handler block or functions called from the handler block, it is
possible to reraise the most recently caught exception with @throw@ or
@throwResume@, respectively.
\begin{cfa}
try {
        ...
} catch( ... ) {
        ... throw;
} catchResume( ... ) {
        ... throwResume;
}
\end{cfa}
The only difference between a raise and a reraise is that reraise does not
create a new exception; instead it continues using the current exception, \ie
no allocation and copy. However the default handler is still set to the one
visible at the raise point, and hence, for termination could refer to data that
is part of an unwound stack frame. To prevent this problem, a new default
handler is generated that does a program-level abort.
\PAB{I don't see how this is different from the normal throw/throwResume.}

\section{Finally Clauses}
Finally clauses are used to perform unconditional clean-up when leaving a
scope and appear at the end of a try statement after any catch clauses:
\begin{cfa}
try {
        GUARDED_BLOCK
} ... // any number or kind of handler clauses
... finally {
        FINALLY_BLOCK
}
\end{cfa}
The @FINALLY_BLOCK@ is executed when the try statement is removed from the
stack, including when the @GUARDED_BLOCK@ finishes, any termination handler
finishes, or during an unwind.
The only time the block is not executed is if the program is exited before
the stack is unwound.

Execution of the finally block should always finish, meaning control runs off
the end of the block. This requirement ensures execution always continues as if the
finally clause is not present, \ie @finally@ is for cleanup not changing control
flow. Because of this requirement, local control flow out of the finally block
is forbidden. The compiler precludes any @break@, @continue@, @fallthru@ or
@return@ that causes control to leave the finally block. Other ways to leave
the finally block, such as a long jump or termination are much harder to check,
and at best require additional run-time overhead, and so are
discouraged.

Not all languages with exceptions have finally clauses. Notably \Cpp does
without it as destructors serve a similar role. Although destructors and
finally clauses can be used in many of the same areas, they have their own
use cases like top-level functions and lambda functions with closures.
Destructors take a bit more work to set up but are much easier to reuse while
finally clauses are good for one-off situations and can easily include local information.

\section{Cancellation}
\label{s:Cancellation}
Cancellation is a stack-level abort, which can be thought of as an
uncatchable termination. It unwinds the entire stack, and when
possible, forwards the cancellation exception to a different stack.

Cancellation is not an exception operation like termination or resumption.
There is no special statement for starting a cancellation; instead the standard
library function @cancel_stack@ is called passing an exception. Unlike a
throw, this exception is not used in matching only to pass information about
the cause of the cancellation.
(This semantics also means matching cannot fail so there is no default handler.)

After @cancel_stack@ is called, the exception is copied into the EHM's
memory and the current stack is
unwound. After that it depends one which stack is being cancelled.
\begin{description}
\item[Main Stack:]
The main stack is the one used by the program main at the start of execution,
and is the only stack in a sequential program. Even in a concurrent program,
the main stack is often used as the environment to start the concurrent threads.
Hence, when the main stack is cancelled there is nowhere else in the program
to go. Hence, after the main stack is unwound, there is a program-level abort.

\item[Thread Stack:]
A thread stack is created for a \CFA @thread@ object or object that satisfies the
@is_thread@ trait. A thread only has two points of communication that must
happen: start and join. A thread must be running to perform a
cancellation (a thread cannot cancel another thread). Therefore, a cancellation must
occur after start and before join, so join is used
for cancellation communication.
After the stack is unwound, the thread halts and waits for
another thread to join with it. The joining thread checks for a cancellation,
and if present, resumes exception @ThreadCancelled@.

\begin{sloppypar}
There is a subtle difference between the explicit join (@join@ function) and
implicit join (from a @thread@'s destructor call). The explicit join takes the default
handler (@defaultResumptionHandler@) from its calling context, which is used if
the exception is not caught. The implicit join does a program abort instead.
\end{sloppypar}

\PAB{uC++ does not have these issues, but catch(...) is not working.}
\begin{lstlisting}[language=uC++]
#include <iostream>
using namespace std;

struct Cl {
        ~Cl() { cout << "C" << endl; }
};
_Coroutine C {
        void main() {
                Cl c;
                try {
                        cancel();
                } catch( ... ) {
                        cout << "..." << endl;
                } _Finally {
                        cout << "F" << endl;
                }
                }
  public:
        void mem() { resume(); }
};
_Task T {
        void main() {
                Cl c;
                try {
                        cancel();
                } catch( ... ) {
                        cout << "..." << endl;
                } _Finally {
                        cout << "F" << endl;
                }
        }
};
int main() {
        C c;
        cout << "here1" << endl;
        c.mem();
        cout << "here2" << endl;
        {
                T t;
        }
        cout << "here3" << endl;
}
\end{lstlisting}

\PAB{This discussion should be its own section.}
This semantics is for safety. If an unwind is triggered while another unwind
is underway only one of them can proceed as they both want to ``consume" the
stack. Letting both try to proceed leads to very undefined behaviour.
Both termination and cancellation involve unwinding and, since the default
@defaultResumptionHandler@ preforms a termination that could more easily
happen in an implicate join inside a destructor. So there is an error message
and an abort instead.

\todo{Perhaps have a more general disucssion of unwind collisions before
this point.}

The recommended way to avoid the abort is to handle the initial resumption
from the implicate join. If required you may put an explicate join inside a
finally clause to disable the check and use the local
@defaultResumptionHandler@ instead.

\item[Coroutine Stack:] A coroutine stack is created for a @coroutine@ object
or object that satisfies the @is_coroutine@ trait. A coroutine only knows of
two other coroutines, its starter and its last resumer. Of the two the last
resumer has the tightest coupling to the coroutine it activated and the most
up-to-date information.

Hence, cancellation of the active coroutine is forwarded to the last resumer
after the stack is unwound. When the resumer restarts, it resumes exception
@CoroutineCancelled@, which is polymorphic over the coroutine type and has a
pointer to the cancelled coroutine.

The resume function also has an assertion that the @defaultResumptionHandler@
for the exception. So it will use the default handler like a regular throw.
\end{description}

\PAB{You should have more test programs that compare \CFA EHM to uC++ EHM.}