Context Navigation

-                      r3b8acfb
+                      re3984a68
 throw/catch as a particular kind of raise/handle.
 These are the two parts that the user writes and may
 be the only two pieces of the EHM that have any syntax in the language.
+be the only two pieces of the EHM that have any syntax in a language.
 \paragraph{Raise}
 The raise is the starting point for exception handling. It marks the beginning
 of exception handling by raising an exception, which passes it to
+The raise is the starting point for exception handling,
+by raising an exception, which passes it to
 the EHM.
 Some well known examples include the @throw@ statements of \Cpp and Java and
 the \code{Python}{raise} statement from Python. In real systems a raise may
 preform some other work (such as memory management) but for the
+the \code{Python}{raise} statement of Python. In real systems, a raise may
+perform some other work (such as memory management) but for the
 purposes of this overview that can be ignored.
 \paragraph{Handle}
+The purpose of most exception operations is to run some user code to handle
+that exception. This code is given, with some other information, in a handler.
+The primary purpose of an EHM is to run some user code to handle a raised
+exception. This code is given, along with some other information,
+in a handler.
 A handler has three common features: the previously mentioned user code, a
 region of code they guard and an exception label/condition that matches
 certain exceptions.
+region of code it guards and an exception label/condition that matches
+against the raised exception.
 Only raises inside the guarded region and raising exceptions that match the
 label can be handled by a given handler.
 If multiple handlers could can handle an exception,
 EHMs will define a rule to pick one, such as ``best match" or ``first found".
+EHMs define a rule to pick one, such as ``best match" or ``first found".
 The @try@ statements of \Cpp, Java and Python are common examples. All three
 …
 \subsection{Propagation}
 After an exception is raised comes what is usually the biggest step for the
+EHM: finding and setting up the handler. The propagation from raise to
+EHM: finding and setting up the handler for execution.
+The propagation from raise to
 handler can be broken up into three different tasks: searching for a handler,
 matching against the handler and installing the handler.
 …
 \paragraph{Searching}
 The EHM begins by searching for handlers that might be used to handle
 the exception. Searching is usually independent of the exception that was
 thrown as it looks for handlers that have the raise site in their guarded
+the exception.
+The search will find handlers that have the raise site in their guarded
 region.
 The search includes handlers in the current function, as well as any in
 …
 \paragraph{Matching}
 Each handler found has to be matched with the raised exception. The exception
 label defines a condition that is used with exception and decides if
+Each handler found is with the raised exception. The exception
+label defines a condition that is used with the exception and decides if
 there is a match or not.
+%
 In languages where the first match is used, this step is intertwined with
 searching; a match check is preformed immediately after the search finds
 a possible handler.
+searching; a match check is performed immediately after the search finds
+a handler.
 \paragraph{Installing}
 After a handler is chosen it must be made ready to run.
+After a handler is chosen, it must be made ready to run.
 The implementation can vary widely to fit with the rest of the
 design of the EHM. The installation step might be trivial or it could be
 …
 If a matching handler is not guaranteed to be found, the EHM needs a
 different course of action for the case where no handler matches.
+different course of action for this case.
 This situation only occurs with unchecked exceptions as checked exceptions
 (such as in Java) can make the guarantee.
 This unhandled action is usually very general, such as aborting the program.
+The unhandled action is usually very general, such as aborting the program.
 \paragraph{Hierarchy}
 …
 exception hierarchy is a natural extension of the object hierarchy.
 Consider the following hierarchy of exceptions:
+Consider the following exception hierarchy:
 \begin{center}
 \input{exception-hierarchy}
 \end{center}
 A handler labeled with any given exception can handle exceptions of that
 type or any child type of that exception. The root of the exception hierarchy
 …
 is usually set up to do most of the work.
 The EHM can return control to many different places,
+The EHM can return control to many different places, where
 the most common are after the handler definition (termination)
 and after the raise (resumption).
 …
 For effective exception handling, additional information is often passed
 from the raise to the handler and back again.
+So far only communication of the exceptions' identity has been covered.
+A common communication method is putting fields into the exception instance
+So far, only communication of the exceptions' identity is covered.
+A common communication method for adding information to an exception
+is putting fields into the exception instance
 and giving the handler access to them.
+Passing the exception by reference instead of by value can allow data to be
+passed in both directions.
+% You can either have pointers/references in the exception, or have p/rs to
+% the exception when it doesn't have to be copied.
+Passing references or pointers allows data at the raise location to be
+updated, passing information in both directions.
 \section{Virtuals}
 \label{s:virtuals}
 Virtual types and casts are not part of \CFA's EHM nor are they required for
 any EHM.
 However, it is one of the best ways to support an exception hierarchy
+an EHM.
+However, one of the best ways to support an exception hierarchy
 is via a virtual hierarchy and dispatch system.
 Ideally, the virtual system would have been part of \CFA before the work
 on exception handling began, but unfortunately it was not.
 Hence, only the features and framework needed for the EHM were
+designed and implemented. Other features were considered to ensure that
+designed and implemented for this thesis.
+Other features were considered to ensure that
 the structure could accommodate other desirable features in the future
 but they were not implemented.
 The rest of this section will only discuss the implemented subset of the
+but are not implemented.
+The rest of this section only discusses the implemented subset of the
 virtual system design.
 …
 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 descendants are its children and its children's descendants.
+Every virtual type also has a list of virtual members. Children inherit
+their parent's list of virtual members but may add new members to it.
+It is important to note that these are virtual members, not virtual methods
+of object-orientated programming, and can be of any type.
+\CFA still supports virtual methods as a special case of virtual members.
+Function pointers that take a pointer to the virtual type are modified
+with each level of inheritance so that refers to the new type.
+This means an object can always be passed to a function in its virtual table
+as if it were a method.
+\todo{Clarify (with an example) virtual methods.}
+Each virtual type has a unique id.
+This id and all the virtual members are combined
+into a virtual table type. Each virtual type has a pointer to a virtual table
+as a hidden field.
+\todo{Might need a diagram for virtual structure.}
+For the purposes of illistration, a proposed -- but unimplemented syntax --
+will be used. Each virtual type is repersented by a trait with an annotation
+that makes it a virtual type. This annotation is empty for a root type, which
+creates a new tree:
+\begin{cfa}
+trait root_type(T) virtual() {}
+\end{cfa}
+The annotation may also refer to any existing virtual type to make this new
+type a child of that type and part of the same tree. The parent may itself
+be a child or a root type and may have any number of existing children.
+\begin{cfa}
+trait child_a(T) virtual(root_type) {}
+trait grandchild(T) virtual(child_a) {}
+trait child_b(T) virtual(root_type) {}
+\end{cfa}
+\todo{Update the diagram in vtable.fig to show the new type tree.}
+Every virtual type also has a list of virtual members and a unique id,
+both are stored in a virtual table.
+Every instance of a virtual type also has a pointer to a virtual table stored
+in it, although there is no per-type virtual table as in many other languages.
+The list of virtual members is built up down the tree. Every virtual type
+inherits the list of virtual members from its parent and may add more
+virtual members to the end of the list which are passed on to its children.
+Again, using the unimplemented syntax this might look like:
+\begin{cfa}
+trait root_type(T) virtual() {
+        const char * to_string(T const & this);
+        unsigned int size;
+}
+trait child_type(T) virtual(root_type) {
+        char * irrelevant_function(int, char);
+}
+\end{cfa}
+% Consider adding a diagram, but we might be good with the explanation.
+As @child_type@ is a child of @root_type@ it has the virtual members of
+@root_type@ (@to_string@ and @size@) as well as the one it declared
+(@irrelivant_function@).
+It is important to note that these are virtual members, and may contain
+arbitrary fields, functions or otherwise.
+The names ``size" and ``align" are reserved for the size and alignment of the
+virtual type, and are always automatically initialized as such.
+The other special case are uses of the trait's polymorphic argument
+(@T@ in the example), which are always updated to refer to the current
+virtual type. This allows functions that refer to to polymorphic argument
+to act as traditional virtual methods (@to_string@ in the example), as the
+object can always be passed to a virtual method in its virtual table.
 Up until this point the virtual system is similar to ones found in
+object-orientated languages but this 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.
+In \CFA, types do not encapsulate any behaviour. Traits are local and
+types can begin to satisfy a trait, stop satisfying a trait or satisfy the same
+trait in a different way at any lexical location in the program.
+In this sense, they are ``open" as they can change at any time.
+object-oriented languages but this is where \CFA diverges.
+Objects encapsulate a single set of methods in each type,
+universally across the entire program,
+and indeed all programs that use that type definition.
+The only way to change any method is to inherit and define a new type with
+its own universal implementation. In this sense,
+these object-oriented types are ``closed" and cannot be altered.
+% Because really they are class oriented.
+In \CFA, types do not encapsulate any code.
+Whether or not satisfies any given assertion, and hence any trait, is
+context sensitive. Types can begin to satisfy a trait, stop satisfying it or
+satisfy the same trait at any lexical location in the program.
+In this sense, an type's implementation in the set of functions and variables
+that allow it to satisfy a trait is ``open" and can change
+throughout the program.
 This capability means it is impossible to pick a single set of functions
 that represent the type's implementation across the program.
+that represent a type's implementation across a program.
 \CFA side-steps this issue by not having a single virtual table for each
 type. A user can define virtual tables that are filled in at their
 declaration and given a name. Anywhere that name is visible, even if it is
 defined locally inside a function (although that means it does not have a
 static lifetime), it can be used.
+defined locally inside a function (although in this case the user must ensure
+it outlives any objects that use it), it can be used.
 Specifically, a virtual type is ``bound" to a virtual table that
 sets the virtual members for that object. The virtual members can be accessed
 …
 from a trait defined by the virtual system, and state that the exception type
 is a virtual type, is a descendant of @exception_t@ (the base exception type)
 and note its virtual table type.
+and allow the user to find the virtual table type.
 % I did have a note about how it is the programmer's responsibility to make
 …
 \CFA provides two kinds of exception handling: termination and resumption.
 These twin operations are the core of \CFA's exception handling mechanism.
 This section will cover the general patterns shared by the two operations and
 then go on to cover the details each individual operation.
+This section covers the general patterns shared by the two operations and
+then goes on to cover the details each individual operation.
 Both operations follow the same set of steps.
 Both start with the user preforming a raise on an exception.
 Then the exception propagates up the stack.
 If a handler is found the exception is caught and the handler is run.
+First, a user raises an exception.
+Second, the exception propagates up the stack, searching for a handler.
+Third, if a handler is found, the exception is caught and the handler is run.
 After that control continues at a raise-dependent location.
+If the search fails a default handler is run and, if it returns, then control
+As an alternate to the third step,
+if a handler is not found, a default handler is run and, if it returns,
+then control
 continues after the raise.
 This general description covers what the two kinds have in common.
+Differences include how propagation is preformed, where exception continues
 after an exception is caught and handled and which default handler is run.
+The differences between the two operations include how propagation is
+performed, where excecution after an exception is handler
+and which default handler is run.
 \subsection{Termination}
 \label{s:Termination}
+Termination handling is the familiar kind and used in most programming
+Termination handling is the familiar kind of handling
+and used in most programming
 languages with exception handling.
 It is a dynamic, non-local goto. If the raised exception is matched and
 …
 @is_termination_exception@ at the call site.
 Through \CFA's trait system, the trait functions are implicitly passed into the
 throw code and the EHM.
+throw code for use by the EHM.
 A new @defaultTerminationHandler@ can be defined in any scope to
 change the throw's behaviour (see below).
+change the throw's behaviour when a handler is not found (see below).
 The throw copies the provided exception into managed memory to ensure
 …
 % How to say propagation starts, its first sub-step is the search.
 Then propagation starts with the search. \CFA uses a ``first match" rule so
 matching is preformed with the copied exception as the search continues.
 It starts from the throwing function and proceeds towards base of the stack,
+matching is performed with the copied exception as the search key.
+It starts from the raise site and proceeds towards base of the stack,
 from callee to caller.
 At each stack frame, a check is made for resumption handlers defined by the
+At each stack frame, a check is made for termination handlers defined by the
 @catch@ clauses of a @try@ statement.
 \begin{cfa}
 …
 \end{cfa}
 When viewed on its own, a try statement simply executes the statements
 in \snake{GUARDED_BLOCK} and when those are finished,
+in the \snake{GUARDED_BLOCK} and when those are finished,
 the try statement finishes.
 …
 invoked functions, all the handlers in these statements are included in the
 search path.
 Hence, if a termination exception is raised these handlers may be matched
+Hence, if a termination exception is raised, these handlers may be matched
 against the exception and may handle it.
 Exception matching checks the handler in each catch clause in the order
 they appear, top to bottom. If the representation of the raised exception type
 is the same or a descendant of @EXCEPTION_TYPE@$_i$ then @NAME@$_i$
+is the same or a descendant of @EXCEPTION_TYPE@$_i$, then @NAME@$_i$
 (if provided) is
 bound to a pointer to the exception and the statements in @HANDLER_BLOCK@$_i$
 …
 freed and control continues after the try statement.
 If no termination handler is found during the search then the default handler
 (\defaultTerminationHandler) visible at the raise statement is run.
 Through \CFA's trait system the best match at the raise statement will be used.
+If no termination handler is found during the search, then the default handler
+(\defaultTerminationHandler) visible at the raise statement is called.
+Through \CFA's trait system the best match at the raise statement is used.
 This function is run and is passed the copied exception.
 If the default handler is run control continues after the raise statement.
+If the default handler finishes, control continues after the raise statement.
 There is a global @defaultTerminationHandler@ that is polymorphic over all
 termination exception types.
-Since it is so general a more specific handler can be
-defined and is used for those types, effectively overriding the handler
-for a particular exception type.
 The global default termination handler performs a cancellation
+(see \vref{s:Cancellation}) on the current stack with the copied exception.
+(as described in \vref{s:Cancellation})
+on the current stack with the copied exception.
+Since it is so general, a more specific handler can be defined,
+overriding the default behaviour for the specific exception types.
 \subsection{Resumption}
 \label{s:Resumption}
+Resumption exception handling is less common than termination but is
+Resumption exception handling is less familar form of exception handling,
+but is
 just as old~\cite{Goodenough75} and is simpler in many ways.
 It is a dynamic, non-local function call. If the raised exception is
 matched a closure is taken from up the stack and executed,
+matched, a closure is taken from up the stack and executed,
 after which the raising function continues executing.
 The common uses for resumption exceptions include
 …
 function once the error is corrected, and
 ignorable events, such as logging where nothing needs to happen and control
+should always continue from the same place.
+should always continue from the raise site.
+Except for the changes to fit into that pattern, resumption exception
+handling is symmetric with termination exception handling, by design
+(see \autoref{s:Termination}).
 A resumption raise is started with the @throwResume@ statement:
 …
 \end{cfa}
 \todo{Decide on a final set of keywords and use them everywhere.}
+It works much the same way as the termination throw.
+The expression must return a reference to a resumption exception,
+where the resumption exception is any type that satisfies the trait
+@is_resumption_exception@ at the call site.
+The assertions from this trait are available to
+the exception system while handling the exception.
+At run-time, no exception copy is made.
+Resumption does not unwind the stack nor otherwise remove values from the
+current scope, so there is no need to manage memory to keep things in scope.
+The EHM then begins propagation. The search starts from the raise in the
+resuming function and proceeds towards 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.
+It works much the same way as the termination raise, except the
+type must satisfy the \snake{is_resumption_exception} that uses the
+default handler: \defaultResumptionHandler.
+This can be specialized for particular exception types.
+At run-time, no exception copy is made. Since
+resumption does not unwind the stack nor otherwise remove values from the
+current scope, there is no need to manage memory to keep the exception
+allocated.
+Then propagation starts with the search,
+following the same search path as termination,
+from the raise site to the base of stack and top of try statement to bottom.
+However, the handlers on try statements are defined by @catchResume@ clauses.
 \begin{cfa}
 try {
 …
+}
 \end{cfa}
-% I wonder if there would be some good central place for this.
 Note that termination handlers and resumption handlers may be used together
 in a single try statement, intermixing @catch@ and @catchResume@ freely.
 Each type of handler only interacts with exceptions from the matching
 kind of raise.
+When a try statement is executed, it simply executes the statements in the
+@GUARDED_BLOCK@ and then finishes.
+However, while the guarded statements are being executed, including any
+invoked functions, all the handlers in these statements are included in the
+search path.
+Hence, if a resumption exception is raised these handlers may be matched
+against the exception and may handle it.
+Exception matching checks the handler in each catch clause in the order
+they appear, top to bottom. If the representation of the raised exception type
+is the same or a descendant of @EXCEPTION_TYPE@$_i$ then @NAME@$_i$
+(if provided) 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, execution continues after the
+the raise statement that raised the handled exception.
+Like termination, if no resumption handler is found during the search,
+the default handler (\defaultResumptionHandler) visible at the raise
+statement is called. It will use the best match at the raise sight according
+to \CFA's overloading rules. The default handler is
+passed the exception given to the raise. When the default handler finishes
+execution continues after the raise statement.
+There is a global \defaultResumptionHandler{} is polymorphic over all
+resumption exceptions and preforms a termination throw on the exception.
+The \defaultTerminationHandler{} can be overridden by providing a new
+function that is a better match.
+Like @catch@ clauses, @catchResume@ clauses have no effect if an exception
+is not raised.
+The matching rules are exactly the same as well.
+The first major difference here is that after
+@EXCEPTION_TYPE@$_i$ is matched and @NAME@$_i$ is bound to the exception,
+@HANDLER_BLOCK@$_i$ is executed right away without first unwinding the stack.
+After the block has finished running control jumps to the raise site, where
+the just handled exception came from, and continues executing after it,
+not after the try statement.
 \subsubsection{Resumption Marking}
 \label{s:ResumptionMarking}
 A key difference between resumption and termination is that resumption does
 not unwind the stack. A side effect that is that when a handler is matched
 and run it's try block (the guarded statements) and every try statement
+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. There presence can lead to
 the recursive resumption problem.
+\todo{Is there a citation for the recursive resumption problem?}
 The recursive resumption problem is any situation where a resumption handler
 …
 When this code is executed, the guarded @throwResume@ starts a
 search and matches the handler in the @catchResume@ clause. This
+call is placed on the stack above the try-block. The second raise then
+searches the same try block and puts another instance of the
+call is placed on the stack above the try-block.
+Now the second raise in the handler searches the same try block,
+matches again and then puts another instance of the
 same handler on the stack leading to infinite recursion.
 While this situation is trivial and easy to avoid, much more complex cycles
 can form with multiple handlers and different exception types.
+To prevent all of these cases, a each try statement is ``marked" from the
+time the exception search reaches it to either when the exception is being
+handled completes the matching handler or when the search reaches the base
+To prevent all of these cases, each try statement is ``marked" from the
+time the exception search reaches it to either when a handler completes
+handling that exception or when the search reaches the base
 of the stack.
 While a try statement is marked, its handlers are never matched, effectively
 …
 for instance, marking just the handlers that caught the exception,
 would also prevent recursive resumption.
+However, these rules mirror what happens with termination.
+The try statements that are marked are the ones that would be removed from
+the stack if this was a termination exception, that is those on the stack
+However, the rules selected mirrors what happens with termination,
+so this reduces the amount of rules and patterns a programmer has to know.
+The marked try statements are the ones that would be removed from
+the stack for a termination exception, \ie those on the stack
 between the handler and the raise statement.
 This symmetry applies to the default handler as well, as both kinds of
 …
         // Only handle IO failure for f3.
+}
 // Can't handle a failure relating to f2 here.
+// Handle a failure relating to f2 further down the stack.
 \end{cfa}
 In this example the file that experienced the IO error is used to decide
 …
 \subsection{Comparison with Reraising}
+A more popular way to allow handlers to match in more detail is to reraise
+the exception after it has been caught, if it could not be handled here.
+On the surface these two features seem interchangeable.
+If @throw;@ (no argument) starts a termination reraise,
+which is the same as a raise but reuses the last caught exception,
+then these two statements have the same behaviour:
+In languages without conditional catch, that is no ability to match an
+exception based on something other than its type, it can be mimicked
+by matching all exceptions of the right type, checking any additional
+conditions inside the handler and re-raising the exception if it does not
+match those.
+Here is a minimal example comparing both patterns, using @throw;@
+(no argument) to start a re-raise.
+\begin{center}
+\begin{tabular}{l r}
 \begin{cfa}
 try {
     do_work_may_throw();
+} catch(exception_t * exc ; can_handle(exc)) {
+} catch(exception_t * exc ;
+                can_handle(exc)) {
     handle(exc);
+}
+\end{cfa}
+\end{cfa}
+&
 \begin{cfa}
 try {
     do_work_may_throw();
 } catch(exception_t * exc) {
+} catch(exception_t * exc) {
     if (can_handle(exc)) {
         handle(exc);
 …
+}
 \end{cfa}
+That is, they will have the same behaviour in isolation.
+Two things can expose differences between these cases.
+One is the existence of multiple handlers on a single try statement.
+A reraise skips all later handlers on this try statement but a conditional
+catch does not.
+Hence, if an earlier handler contains a reraise later handlers are
+implicitly skipped, with a conditional catch they are not.
+Still, they are equivalently powerful,
+both can be used two mimic the behaviour of the other,
+as reraise can pack arbitrary code in the handler and conditional catches
+can put arbitrary code in the predicate.
+% I was struggling with a long explanation about some simple solutions,
+% like repeating a condition on later handlers, and the general solution of
+% merging everything together. I don't think it is useful though unless its
+% for a proof.
+% https://en.cppreference.com/w/cpp/language/throw
+The question then becomes ``Which is a better default?"
+We believe that not skipping possibly useful handlers is a better default.
+If a handler can handle an exception it should and if the handler can not
+handle the exception then it is probably safer to have that explicitly
+described in the handler itself instead of implicitly described by its
+ordering with other handlers.
+% Or you could just alter the semantics of the throw statement. The handler
+% index is in the exception so you could use it to know where to start
+% searching from in the current try statement.
+% No place for the `goto else;` metaphor.
+The other issue is all of the discussion above assumes that the only
+way to tell apart two raises is the exception being raised and the remaining
+search path.
+This is not true generally, the current state of the stack can matter in
+a number of cases, even only for a stack trace after an program abort.
+But \CFA has a much more significant need of the rest of the stack, the
+default handlers for both termination and resumption.
+% For resumption it turns out it is possible continue a raise after the
+% exception has been caught, as if it hadn't been caught in the first place.
+This becomes a problem combined with the stack unwinding used in termination
+exception handling.
+The stack is unwound before the handler is installed, and hence before any
+reraises can run. So if a reraise happens the previous stack is gone,
+the place on the stack where the default handler was supposed to run is gone,
+if the default handler was a local function it may have been unwound too.
+There is no reasonable way to restore that information, so the reraise has
+to be considered as a new raise.
+This is the strongest advantage conditional catches have over reraising,
+they happen before stack unwinding and avoid this problem.
+% The one possible disadvantage of conditional catch is that it runs user
+% code during the exception search. While this is a new place that user code
+% can be run destructors and finally clauses are already run during the stack
+% unwinding.
+\end{tabular}
+\end{center}
+At first glance catch-and-reraise may appear to just be a quality of life
+feature, but there are some significant differences between the two
+stratagies.
+A simple difference that is more important for \CFA than many other languages
+is that the raise site changes, with a re-raise but does not with a
+conditional catch.
+This is important in \CFA because control returns to the raise site to run
+the per-site default handler. Because of this only a conditional catch can
+allow the original raise to continue.
+The more complex issue comes from the difference in how conditional
+catches and re-raises handle multiple handlers attached to a single try
+statement. A conditional catch will continue checking later handlers while
+a re-raise will skip them.
+If the different handlers could handle some of the same exceptions,
+translating a try statement that uses one to use the other can quickly
+become non-trivial:
+\noindent
+Original, with conditional catch:
+\begin{cfa}
+...
+} catch (an_exception * e ; check_a(e)) {
+        handle_a(e);
+} catch (exception_t * e ; check_b(e)) {
+        handle_b(e);
+}
+\end{cfa}
+Translated, with re-raise:
+\begin{cfa}
+...
+} catch (exception_t * e) {
+        an_exception * an_e = (virtual an_exception *)e;
+        if (an_e && check_a(an_e)) {
+                handle_a(an_e);
+        } else if (check_b(e)) {
+                handle_b(e);
+        } else {
+                throw;
+        }
+}
+\end{cfa}
+(There is a simpler solution if @handle_a@ never raises exceptions,
+using nested try statements.)
+% } catch (an_exception * e ; check_a(e)) {
+%     handle_a(e);
+% } catch (exception_t * e ; !(virtual an_exception *)e && check_b(e)) {
+%     handle_b(e);
+% }
+%
+% https://www.cplusplus.com/reference/exception/current_exception/
+%   `exception_ptr current_exception() noexcept;`
+% https://www.python.org/dev/peps/pep-0343/
+% } catch (an_exception * e)
+%   if (check_a(e)) {
+%     handle_a(e);
+%   } else throw;
+% } catch (exception_t * e)
+%   if (check_b(e)) {
+%     handle_b(e);
+%   } else throw;
+% }
+In similar simple examples translating from re-raise to conditional catch
+takes less code but it does not have a general trivial solution either.
+So, given that the two patterns do not trivially translate into each other,
+it becomes a matter of which on should be encouraged and made the default.
+From the premise that if a handler that could handle an exception then it
+should, it follows that checking as many handlers as possible is preferred.
+So conditional catch and checking later handlers is a good default.
 \section{Finally Clauses}
 …
 Not all languages with unwinding have finally clauses. Notably \Cpp does
 without it as descructors, and the RAII design pattern, serve a similar role.
 Although destructors and finally clauses can be used in the same cases,
+without it as destructors, and the RAII design pattern, serve a similar role.
+Although destructors and finally clauses can be used for the same cases,
 they have their own strengths, similar to top-level function and lambda
 functions with closures.
 Destructors take more work for their first use, but if there is clean-up code
 that needs to be run every time a type is used they soon become much easier
 to set-up.
+Destructors take more work to create, but if there is clean-up code
+that needs to be run every time a type is used, they are much easier
+to set-up for each use. % It's automatic.
 On the other hand finally clauses capture the local context, so is easy to
 use when the clean-up is not dependent on the type of a variable or requires
 information from multiple variables.
-% To Peter: I think these are the main points you were going for.
 \section{Cancellation}
 …
 raise, this exception is not used in matching only to pass information about
 the cause of the cancellation.
+(This also means matching cannot fail so there is no default handler.)
+Finally, as no handler is provided, there is no default handler.
 After @cancel_stack@ is called the exception is copied into the EHM's memory
 …
 After the main stack is unwound there is a program-level abort.
 There are two reasons for these semantics.
 The first is that it had to do this abort.
 in a sequential program as there is nothing else to notify and the simplicity
 of keeping the same behaviour in sequential and concurrent programs is good.
+Also, even in concurrent programs there may not currently be any other stacks
 and even if other stacks do exist, main has no way to know where they are.
+The first reason for this behaviour is for sequential programs where there
+is only one stack, and hence to stack to pass information to.
+Second, even in concurrent programs, the main stack has no dependency
+on another stack and no reliable way to find another living stack.
+Finally, keeping the same behaviour in both sequential and concurrent
+programs is simple and easy to understand.
 \paragraph{Thread Stack}
 …
 With explicit join and a default handler that triggers a cancellation, it is
+possible to cascade an error across any number of threads, cleaning up each
+possible to cascade an error across any number of threads,
+alternating between the resumption (possibly termination) and cancellation,
+cleaning up each
 in turn, until the error is handled or the main thread is reached.
 …
 caller's context and passes it to the internal report.
+A coroutine knows of two other coroutines, its starter and its last resumer.
+A coroutine only knows of two other coroutines,
+its starter and its last resumer.
 The starter has a much more distant connection, while the last resumer just
 (in terms of coroutine state) called resume on this coroutine, so the message
 …
 With a default handler that triggers a cancellation, it is possible to
+cascade an error across any number of coroutines, cleaning up each in turn,
+cascade an error across any number of coroutines,
+alternating between the resumption (possibly termination) and cancellation,
+cleaning up each in turn,
 until the error is handled or a thread stack is reached.

Note: See TracChangeset for help on using the changeset viewer.

Context Navigation

Changeset e3984a68 for doc/theses

Legend:

TabularUnified doc/theses/andrew_beach_MMath/features.tex ¶

Download in other formats: