Context Navigation

← Previous Change
Next Change →

features.tex

Timestamp:

Sep 9, 2021, 3:56:32 PM (4 years ago)

Author:

Thierry Delisle <tdelisle@…>

Branches:

ADT, ast-experimental, enum, forall-pointer-decay, master, pthread-emulation, qualifiedEnum

Children:

d0b9247

Parents:

dd1cc02 (diff), d8d512e (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the (diff) links above to see all the changes relative to each parent.

Message:

Merge branch 'master' of plg.uwaterloo.ca:software/cfa/cfa-cc

File:

: 1 edited

doc/theses/andrew_beach_MMath/features.tex (modified) (34 diffs)

Legend:

: Unmodified
: Added
: Removed

doc/theses/andrew_beach_MMath/features.tex

-              rdd1cc02
+              r5a40e4e
 \paragraph{Raise}
 The raise is the starting point for exception handling
+The raise is the starting point for exception handling,
 by raising an exception, which passes it to
 the EHM.
 …
 \paragraph{Handle}
 The primary purpose of an EHM is to run some user code to handle a raised
+exception. This code is given, with some other information, in a handler.
+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 it guards, and an exception label/condition that matches
 the raised exception.
+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.
 …
 The @try@ statements of \Cpp, Java and Python are common examples. All three
+show the common features of guarded region, raise, matching and handler.
+\begin{cfa}
+try {                           // guarded region
+        ...
+        throw exception;        // raise
+        ...
+} catch( exception ) {  // matching condition, with exception label
+        ...                             // handler code
+}
+\end{cfa}
+also show another common feature of handlers, they are grouped by the guarded
+region.
 \subsection{Propagation}
 After an exception is raised comes what is usually the biggest step for the
+EHM: finding and setting up the handler for execution. 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. The search is restricted to
 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 is matched with the raised exception. The exception
+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 performed immediately after the search finds
 …
 different course of action for this case.
 This situation only occurs with unchecked exceptions as checked exceptions
 (such as in Java) are guaranteed to find a matching handler.
+(such as in Java) can make the guarantee.
 The unhandled action is usually very general, such as aborting the program.
 …
 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
 (here \code{C}{exception}) acts as a catch-all, leaf types catch single types,
+(here \code{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
+the ability for libraries to add new exception types and the isolation
 between different sub-hierarchies.
 This design is used in \CFA even though it is not a object-orientated
 …
 For effective exception handling, additional information is often passed
 from the raise to the handler and back again.
+So far, only communication of the exception's identity is covered.
+A common communication method for passing more information 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.
+Using reference fields pointing to data at the raise location allows 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
 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 should have been part of \CFA before the work
+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 for this thesis. 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 are not implemented.
 The rest of this section only discusses the implemented subset of the
 virtual-system design.
+virtual system design.
 The virtual system supports multiple ``trees" of types. Each tree is
 …
 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.
+\PAB{Need to look at these when done.
+\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 illustration, a proposed -- but unimplemented syntax --
+will be used. Each virtual type is represented 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.
+% OK, for some reason the b and t positioning options are reversed here.
+\begin{minipage}[b]{0.6\textwidth}
+\begin{cfa}
+trait child_a(T) virtual(root_type) {}
+trait grandchild(T) virtual(child_a) {}
+trait child_b(T) virtual(root_type) {}
+\end{cfa}
+\end{minipage}
+\begin{minipage}{0.4\textwidth}
+\begin{center}
+\input{virtual-tree}
+\end{center}
+\end{minipage}
+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
+(@irrelevant_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 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. Even if a type inherits and adds methods, it still encapsulate a
+single set of methods. In this sense,
+object-oriented types are ``closed" and cannot be altered.
+In \CFA, types do not encapsulate any code. Traits are local for each function and
+types can satisfy a local trait, stop satisfying it or, satisfy the same
+trait in a different way at any lexical location in the program where a function is call.
+In 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.
+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 a type's implementation across a program.
 …
 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 \PAB{What does this mean? (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
 through the object.
+This means virtual tables are declared and named in \CFA.
+They are declared as variables, using the type
+@vtable(VIRTUAL_TYPE)@ and any valid name. For example:
+\begin{cfa}
+vtable(virtual_type_name) table_name;
+\end{cfa}
+Like any variable they may be forward declared with the @extern@ keyword.
+Forward declaring virtual tables is relatively common.
+Many virtual types have an ``obvious" implementation that works in most
+cases.
+A pattern that has appeared in the early work using virtuals is to
+implement a virtual table with the the obvious definition and place a forward
+declaration of it in the header beside the definition of the virtual type.
+Even on the full declaration, no initializer should be used.
+Initialization is automatic.
+The type id and special virtual members ``size" and ``align" only depend on
+the virtual type, which is fixed given the type of the virtual table and
+so the compiler fills in a fixed value.
+The other virtual members are resolved, using the best match to the member's
+name and type, in the same context as the virtual table is declared using
+\CFA's normal resolution rules.
 While much of the virtual infrastructure is created, it is currently only used
 …
 @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
+\section{Exceptions}
+The syntax for declaring an exception is the same as declaring a structure
+except the keyword that is swapped out:
+\begin{cfa}
+exception TYPE_NAME {
+        FIELDS
+};
+\end{cfa}
+Fields are filled in the same way as a structure as well. However an extra
+field is added that contains the pointer to the virtual table.
+It must be explicitly initialized by the user when the exception is
+constructed.
+Here is an example of declaring an exception type along with a virtual table,
+assuming the exception has an ``obvious" implementation and a default
+virtual table makes sense.
+\begin{minipage}[t]{0.4\textwidth}
+Header:
+\begin{cfa}
+exception Example {
+        int data;
+};
+extern vtable(Example)
+        example_base_vtable;
+\end{cfa}
+\end{minipage}
+\begin{minipage}[t]{0.6\textwidth}
+Source:
+\begin{cfa}
+vtable(Example) example_base_vtable
+\end{cfa}
+\vfil
+\end{minipage}
+%\subsection{Exception Details}
+This is the only interface needed when raising and handling exceptions.
+However it is actually a short hand for a more complex
+trait based interface.
+The language views exceptions through a series of traits.
+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}
 …
 };
 \end{cfa}
 The trait is defined over two types, the exception type and the virtual table
+The trait is defined over two types: the exception type and the virtual table
 type. Each exception type should have a single virtual table type.
 There are no actual assertions in this trait because the trait system
 …
 completing the virtual system). The imaginary assertions would probably come
 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.
+is a virtual type, is a descendant of @exception_t@ (the base exception 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
 …
 };
 \end{cfa}
 Both traits ensure a pair of types are an exception type, its virtual table
 type,
+Both traits ensure a pair of types is an exception type, its virtual table
+type
 and defines one of the two default handlers. The default handlers are used
 as fallbacks and are discussed in detail in \vref{s:ExceptionHandling}.
 …
 facing way. So these three macros are provided to wrap these traits to
 simplify referring to the names:
 @IS_EXCEPTION@, @IS_TERMINATION_EXCEPTION@, and @IS_RESUMPTION_EXCEPTION@.
+@IS_EXCEPTION@, @IS_TERMINATION_EXCEPTION@ and @IS_RESUMPTION_EXCEPTION@.
 All three take one or two arguments. The first argument is the name of the
 …
 These twin operations are the core of \CFA's exception handling mechanism.
 This section covers the general patterns shared by the two operations and
 then goes on to cover the details of each individual operation.
+then goes on to cover the details each individual operation.
 Both operations follow the same set of steps.
 First, a user raises an exception.
 Second, the exception propagates up the stack.
+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.
+Fourth, if a handler is not found, 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.
+The differences in the two operations include how propagation is performed, where execution 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 execution continues after an exception is handled
+and which default handler is run.
 \subsection{Termination}
 \label{s:Termination}
+Termination handling is the familiar EHM 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
 …
 Then propagation starts with the search. \CFA uses a ``first match" rule so
 matching is performed with the copied exception as the search key.
 It starts from the raise in the throwing function and proceeds towards the base of the stack,
+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 termination handlers defined by the
 …
 \end{cfa}
 When viewed on its own, a try statement simply executes the statements
 in the \snake{GUARDED_BLOCK}, and when those are finished,
+in the \snake{GUARDED_BLOCK} and when those are finished,
 the try statement finishes.
 …
 termination exception types.
 The global default termination handler performs a cancellation
+(see \vref{s:Cancellation} for the justification) on the current stack with the copied exception.
+Since it is so general, a more specific handler is usually
+defined, possibly with a detailed message, and used for specific exception type, effectively overriding the default handler.
+(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 the less familar EHM, 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
 …
 function once the error is corrected, and
 ignorable events, such as logging where nothing needs to happen and control
+should always continue from the raise point.
+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:
 …
 throwResume EXPRESSION;
 \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, since
+% The new keywords are currently ``experimental" and not used in this work.
+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, so there is no need to manage memory to keep the exception in scope.
+Then propagation starts with the search. It 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.
+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}
+% PAB, you say this above.
+% 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,
+% then 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 performs a termination throw on the exception.
+% The \defaultTerminationHandler{} can be overridden by providing a new
+% function that is a better match.
+The @GUARDED_BLOCK@ and its associated nested guarded statements work the same
+for resumption as for termination, as does exception matching at each
+@catchResume@. Similarly, if no resumption handler is found during the search,
+then the currently visible default handler (\defaultResumptionHandler) is
+called and control continues after the raise statement if it returns. Finally,
+there is also a global @defaultResumptionHandler@, which can be overridden,
+that is polymorphic over all resumption exceptions but performs a termination
+throw on the exception rather than a cancellation.
+Throwing the exception in @defaultResumptionHandler@ has the positive effect of
+walking the stack a second time for a recovery handler. Hence, a programmer has
+two chances for help with a problem, fixup or recovery, should either kind of
+handler appear on the stack. However, this dual stack walk leads to following
+apparent anomaly:
+\begin{cfa}
+try {
+        throwResume E;
+} catch (E) {
+        // this handler runs
+}
+\end{cfa}
+because the @catch@ appears to handle a @throwResume@, but a @throwResume@ only
+matches with @catchResume@. The anomaly results because the unmatched
+@catchResuem@, calls @defaultResumptionHandler@, which in turn throws @E@.
+% I wonder if there would be some good central place for this.
+Note, termination and resumption handlers may be used together
+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.
+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}
 …
 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 \emph{recursive resumption problem}.
+the recursive resumption problem.\cite{Buhr00a}
+% Other possible citation is MacLaren77, but the form is different.
 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. Now the second raise in the handler
+searches the same try block, matches, 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.  The key point is
+that the programmer's intuition expects every raise in a handler to start
+searching \emph{below} the @try@ statement, making it difficult to understand
+and fix the problem.
+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, each try statement is ``marked" from the
 time the exception search reaches it to either when a matching handler
 completes or when the search reaches the base
+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, the rule selected mirrors what happens with termination,
 and hence, matches programmer intuition that a raise searches below a try.
 In detail, the marked try statements are the ones that would be removed from
+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.
 …
 \subsection{Comparison with Reraising}
+Without conditional catch, the only approach to match in more detail is to reraise
+the exception after it has been caught, if it could not be handled.
+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|l}
+\begin{tabular}{l r}
 \begin{cfa}
 try {
         do_work_may_throw();
 } catch(excep_t * ex; can_handle(ex)) {
         handle(ex);
+}
+    do_work_may_throw();
+} catch(exception_t * exc ;
+                can_handle(exc)) {
+    handle(exc);
+}
 \end{cfa}
+&
 \begin{cfa}
 try {
+        do_work_may_throw();
+} catch(excep_t * ex) {
+        if (can_handle(ex)) {
+                handle(ex);
+    do_work_may_throw();
+} catch(exception_t * exc) {
+    if (can_handle(exc)) {
+        handle(exc);
+    } else {
+        throw;
+    }
+}
+\end{cfa}
+\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}
+\end{tabular}
+\end{center}
+Notice catch-and-reraise increases complexity by adding additional data and
+code to the exception process. Nevertheless, catch-and-reraise can simulate
+conditional catch straightforwardly, when exceptions are disjoint, \ie no
+inheritance.
+However, catch-and-reraise simulation becomes unusable for exception inheritance.
+\begin{flushleft}
+\begin{cfa}[xleftmargin=6pt]
+exception E1;
+exception E2(E1); // inheritance
+\end{cfa}
+\begin{tabular}{l|l}
+\begin{cfa}
+try {
+        ... foo(); ... // raise E1/E2
+        ... bar(); ... // raise E1/E2
+} catch( E2 e; e.rtn == foo ) {
+        ...
+} catch( E1 e; e.rtn == foo ) {
+        ...
+} catch( E1 e; e.rtn == bar ) {
+        ...
+}
+\end{cfa}
+&
+\begin{cfa}
+try {
+        ... foo(); ...
+        ... bar(); ...
+} catch( E2 e ) {
+        if ( e.rtn == foo ) { ...
+        } else throw; // reraise
+} catch( E1 e ) {
+        if (e.rtn == foo) { ...
+        } else if (e.rtn == bar) { ...
+        else throw; // reraise
+}
+\end{cfa}
+\end{tabular}
+\end{flushleft}
+The derived exception @E2@ must be ordered first in the catch list, otherwise
+the base exception @E1@ catches both exceptions. In the catch-and-reraise code
+(right), the @E2@ handler catches exceptions from both @foo@ and
+@bar@. However, the reraise misses the following catch clause. To fix this
+problem, an enclosing @try@ statement is need to catch @E2@ for @bar@ from the
+reraise, and its handler must duplicate the inner handler code for @bar@. To
+generalize, this fix for any amount of inheritance and complexity of try
+statement requires a technique called \emph{try-block
+splitting}~\cite{Krischer02}, which is not discussed in this thesis. It is
+sufficient to state that conditional catch is more expressive than
+catch-and-reraise in terms of complexity.
+\begin{comment}
+That is, they 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 for a 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.
+(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/
+\end{comment}
+% } 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}
 …
 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.
+finishes or during an unwind.
 The only time the block is not executed is if the program is exited before
 the stack is unwound.
 …
 they have their own strengths, similar to top-level function and lambda
 functions with closures.
 Destructors take more work for their creation, but if there is clean-up code
+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.
+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
 …
 raise, this exception is not used in matching only to pass information about
 the cause of the cancellation.
 Finaly, since a cancellation only unwinds and forwards, 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.
 The reasons for this semantics in a sequential program is that there is no more code to execute.
 This semantics also applies to concurrent programs, too, even if threads are running.
+That is, if any threads starts a cancellation, it implies all threads terminate.
 Keeping the same behaviour in sequential and concurrent programs is simple.
+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 only 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.
-\PAB{Part of this I do not understand. A cancellation cannot be caught. But you
-talk about handling a cancellation in the last sentence. Which is correct?}

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

Context Navigation

Changeset 5a40e4e for doc/theses/andrew_beach_MMath/features.tex

Legend:

doc/theses/andrew_beach_MMath/features.tex

Download in other formats: