Changeset e3984a68


Ignore:
Timestamp:
Aug 18, 2021, 4:34:40 PM (3 years ago)
Author:
Andrew Beach <ajbeach@…>
Branches:
ADT, ast-experimental, enum, forall-pointer-decay, jacob/cs343-translation, master, pthread-emulation, qualifiedEnum
Children:
ed4d7c1
Parents:
3b8acfb
Message:

Andrew MMath: Added in Peter's feedback to the feature's chapter.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/theses/andrew_beach_MMath/features.tex

    r3b8acfb re3984a68  
    1616throw/catch as a particular kind of raise/handle.
    1717These are the two parts that the user writes and may
    18 be the only two pieces of the EHM that have any syntax in the language.
     18be the only two pieces of the EHM that have any syntax in a language.
    1919
    2020\paragraph{Raise}
    21 The raise is the starting point for exception handling. It marks the beginning
    22 of exception handling by raising an exception, which passes it to
     21The raise is the starting point for exception handling,
     22by raising an exception, which passes it to
    2323the EHM.
    2424
    2525Some well known examples include the @throw@ statements of \Cpp and Java and
    26 the \code{Python}{raise} statement from Python. In real systems a raise may
    27 preform some other work (such as memory management) but for the
     26the \code{Python}{raise} statement of Python. In real systems, a raise may
     27perform some other work (such as memory management) but for the
    2828purposes of this overview that can be ignored.
    2929
    3030\paragraph{Handle}
    31 The purpose of most exception operations is to run some user code to handle
    32 that exception. This code is given, with some other information, in a handler.
     31The primary purpose of an EHM is to run some user code to handle a raised
     32exception. This code is given, along with some other information,
     33in a handler.
    3334
    3435A handler has three common features: the previously mentioned user code, a
    35 region of code they guard and an exception label/condition that matches
    36 certain exceptions.
     36region of code it guards and an exception label/condition that matches
     37against the raised exception.
    3738Only raises inside the guarded region and raising exceptions that match the
    3839label can be handled by a given handler.
    3940If multiple handlers could can handle an exception,
    40 EHMs will define a rule to pick one, such as ``best match" or ``first found".
     41EHMs define a rule to pick one, such as ``best match" or ``first found".
    4142
    4243The @try@ statements of \Cpp, Java and Python are common examples. All three
     
    4647\subsection{Propagation}
    4748After an exception is raised comes what is usually the biggest step for the
    48 EHM: finding and setting up the handler. The propagation from raise to
     49EHM: finding and setting up the handler for execution.
     50The propagation from raise to
    4951handler can be broken up into three different tasks: searching for a handler,
    5052matching against the handler and installing the handler.
     
    5254\paragraph{Searching}
    5355The EHM begins by searching for handlers that might be used to handle
    54 the exception. Searching is usually independent of the exception that was
    55 thrown as it looks for handlers that have the raise site in their guarded
     56the exception.
     57The search will find handlers that have the raise site in their guarded
    5658region.
    5759The search includes handlers in the current function, as well as any in
     
    5961
    6062\paragraph{Matching}
    61 Each handler found has to be matched with the raised exception. The exception
    62 label defines a condition that is used with exception and decides if
     63Each handler found is with the raised exception. The exception
     64label defines a condition that is used with the exception and decides if
    6365there is a match or not.
    64 
     66%
    6567In languages where the first match is used, this step is intertwined with
    66 searching; a match check is preformed immediately after the search finds
    67 a possible handler.
     68searching; a match check is performed immediately after the search finds
     69a handler.
    6870
    6971\paragraph{Installing}
    70 After a handler is chosen it must be made ready to run.
     72After a handler is chosen, it must be made ready to run.
    7173The implementation can vary widely to fit with the rest of the
    7274design of the EHM. The installation step might be trivial or it could be
     
    7577
    7678If a matching handler is not guaranteed to be found, the EHM needs a
    77 different course of action for the case where no handler matches.
     79different course of action for this case.
    7880This situation only occurs with unchecked exceptions as checked exceptions
    7981(such as in Java) can make the guarantee.
    80 This unhandled action is usually very general, such as aborting the program.
     82The unhandled action is usually very general, such as aborting the program.
    8183
    8284\paragraph{Hierarchy}
     
    8587exception hierarchy is a natural extension of the object hierarchy.
    8688
    87 Consider the following hierarchy of exceptions:
     89Consider the following exception hierarchy:
    8890\begin{center}
    8991\input{exception-hierarchy}
    9092\end{center}
    91 
    9293A handler labeled with any given exception can handle exceptions of that
    9394type or any child type of that exception. The root of the exception hierarchy
     
    110111is usually set up to do most of the work.
    111112
    112 The EHM can return control to many different places,
     113The EHM can return control to many different places, where
    113114the most common are after the handler definition (termination)
    114115and after the raise (resumption).
     
    117118For effective exception handling, additional information is often passed
    118119from the raise to the handler and back again.
    119 So far only communication of the exceptions' identity has been covered.
    120 A common communication method is putting fields into the exception instance
     120So far, only communication of the exceptions' identity is covered.
     121A common communication method for adding information to an exception
     122is putting fields into the exception instance
    121123and giving the handler access to them.
    122 Passing the exception by reference instead of by value can allow data to be
    123 passed in both directions.
     124% You can either have pointers/references in the exception, or have p/rs to
     125% the exception when it doesn't have to be copied.
     126Passing references or pointers allows data at the raise location to be
     127updated, passing information in both directions.
    124128
    125129\section{Virtuals}
    126130\label{s:virtuals}
    127131Virtual types and casts are not part of \CFA's EHM nor are they required for
    128 any EHM.
    129 However, it is one of the best ways to support an exception hierarchy
     132an EHM.
     133However, one of the best ways to support an exception hierarchy
    130134is via a virtual hierarchy and dispatch system.
    131 
    132135Ideally, the virtual system would have been part of \CFA before the work
    133136on exception handling began, but unfortunately it was not.
    134137Hence, only the features and framework needed for the EHM were
    135 designed and implemented. Other features were considered to ensure that
     138designed and implemented for this thesis.
     139Other features were considered to ensure that
    136140the structure could accommodate other desirable features in the future
    137 but they were not implemented.
    138 The rest of this section will only discuss the implemented subset of the
     141but are not implemented.
     142The rest of this section only discusses the implemented subset of the
    139143virtual system design.
    140144
     
    144148number of children.
    145149Any type that belongs to any of these trees is called a virtual type.
    146 
    147150% A type's ancestors are its parent and its parent's ancestors.
    148151% The root type has no ancestors.
    149152% A type's descendants are its children and its children's descendants.
    150153
    151 Every virtual type also has a list of virtual members. Children inherit
    152 their parent's list of virtual members but may add new members to it.
    153 It is important to note that these are virtual members, not virtual methods
    154 of object-orientated programming, and can be of any type.
    155 
    156 \CFA still supports virtual methods as a special case of virtual members.
    157 Function pointers that take a pointer to the virtual type are modified
    158 with each level of inheritance so that refers to the new type.
    159 This means an object can always be passed to a function in its virtual table
    160 as if it were a method.
    161 \todo{Clarify (with an example) virtual methods.}
    162 
    163 Each virtual type has a unique id.
    164 This id and all the virtual members are combined
    165 into a virtual table type. Each virtual type has a pointer to a virtual table
    166 as a hidden field.
    167 \todo{Might need a diagram for virtual structure.}
     154For the purposes of illistration, a proposed -- but unimplemented syntax --
     155will be used. Each virtual type is repersented by a trait with an annotation
     156that makes it a virtual type. This annotation is empty for a root type, which
     157creates a new tree:
     158\begin{cfa}
     159trait root_type(T) virtual() {}
     160\end{cfa}
     161The annotation may also refer to any existing virtual type to make this new
     162type a child of that type and part of the same tree. The parent may itself
     163be a child or a root type and may have any number of existing children.
     164\begin{cfa}
     165trait child_a(T) virtual(root_type) {}
     166trait grandchild(T) virtual(child_a) {}
     167trait child_b(T) virtual(root_type) {}
     168\end{cfa}
     169\todo{Update the diagram in vtable.fig to show the new type tree.}
     170
     171Every virtual type also has a list of virtual members and a unique id,
     172both are stored in a virtual table.
     173Every instance of a virtual type also has a pointer to a virtual table stored
     174in it, although there is no per-type virtual table as in many other languages.
     175
     176The list of virtual members is built up down the tree. Every virtual type
     177inherits the list of virtual members from its parent and may add more
     178virtual members to the end of the list which are passed on to its children.
     179Again, using the unimplemented syntax this might look like:
     180\begin{cfa}
     181trait root_type(T) virtual() {
     182        const char * to_string(T const & this);
     183        unsigned int size;
     184}
     185
     186trait child_type(T) virtual(root_type) {
     187        char * irrelevant_function(int, char);
     188}
     189\end{cfa}
     190% Consider adding a diagram, but we might be good with the explanation.
     191
     192As @child_type@ is a child of @root_type@ it has the virtual members of
     193@root_type@ (@to_string@ and @size@) as well as the one it declared
     194(@irrelivant_function@).
     195
     196It is important to note that these are virtual members, and may contain   
     197arbitrary fields, functions or otherwise.
     198The names ``size" and ``align" are reserved for the size and alignment of the
     199virtual type, and are always automatically initialized as such.
     200The other special case are uses of the trait's polymorphic argument
     201(@T@ in the example), which are always updated to refer to the current
     202virtual type. This allows functions that refer to to polymorphic argument
     203to act as traditional virtual methods (@to_string@ in the example), as the
     204object can always be passed to a virtual method in its virtual table.
    168205
    169206Up until this point the virtual system is similar to ones found in
    170 object-orientated languages but this where \CFA diverges. Objects encapsulate a
    171 single set of behaviours in each type, universally across the entire program,
    172 and indeed all programs that use that type definition. In this sense, the
    173 types are ``closed" and cannot be altered.
    174 
    175 In \CFA, types do not encapsulate any behaviour. Traits are local and
    176 types can begin to satisfy a trait, stop satisfying a trait or satisfy the same
    177 trait in a different way at any lexical location in the program.
    178 In this sense, they are ``open" as they can change at any time.
     207object-oriented languages but this is where \CFA diverges.
     208Objects encapsulate a single set of methods in each type,
     209universally across the entire program,
     210and indeed all programs that use that type definition.
     211The only way to change any method is to inherit and define a new type with
     212its own universal implementation. In this sense,
     213these object-oriented types are ``closed" and cannot be altered.
     214% Because really they are class oriented.
     215
     216In \CFA, types do not encapsulate any code.
     217Whether or not satisfies any given assertion, and hence any trait, is
     218context sensitive. Types can begin to satisfy a trait, stop satisfying it or
     219satisfy the same trait at any lexical location in the program.
     220In this sense, an type's implementation in the set of functions and variables
     221that allow it to satisfy a trait is ``open" and can change
     222throughout the program.
    179223This capability means it is impossible to pick a single set of functions
    180 that represent the type's implementation across the program.
     224that represent a type's implementation across a program.
    181225
    182226\CFA side-steps this issue by not having a single virtual table for each
    183227type. A user can define virtual tables that are filled in at their
    184228declaration and given a name. Anywhere that name is visible, even if it is
    185 defined locally inside a function (although that means it does not have a
    186 static lifetime), it can be used.
     229defined locally inside a function (although in this case the user must ensure
     230it outlives any objects that use it), it can be used.
    187231Specifically, a virtual type is ``bound" to a virtual table that
    188232sets the virtual members for that object. The virtual members can be accessed
     
    223267from a trait defined by the virtual system, and state that the exception type
    224268is a virtual type, is a descendant of @exception_t@ (the base exception type)
    225 and note its virtual table type.
     269and allow the user to find the virtual table type.
    226270
    227271% I did have a note about how it is the programmer's responsibility to make
     
    273317\CFA provides two kinds of exception handling: termination and resumption.
    274318These twin operations are the core of \CFA's exception handling mechanism.
    275 This section will cover the general patterns shared by the two operations and
    276 then go on to cover the details each individual operation.
     319This section covers the general patterns shared by the two operations and
     320then goes on to cover the details each individual operation.
    277321
    278322Both operations follow the same set of steps.
    279 Both start with the user preforming a raise on an exception.
    280 Then the exception propagates up the stack.
    281 If a handler is found the exception is caught and the handler is run.
     323First, a user raises an exception.
     324Second, the exception propagates up the stack, searching for a handler.
     325Third, if a handler is found, the exception is caught and the handler is run.
    282326After that control continues at a raise-dependent location.
    283 If the search fails a default handler is run and, if it returns, then control
     327As an alternate to the third step,
     328if a handler is not found, a default handler is run and, if it returns,
     329then control
    284330continues after the raise.
    285331
    286 This general description covers what the two kinds have in common.
    287 Differences include how propagation is preformed, where exception continues
    288 after an exception is caught and handled and which default handler is run.
     332The differences between the two operations include how propagation is
     333performed, where excecution after an exception is handler
     334and which default handler is run.
    289335
    290336\subsection{Termination}
    291337\label{s:Termination}
    292 Termination handling is the familiar kind and used in most programming
     338Termination handling is the familiar kind of handling
     339and used in most programming
    293340languages with exception handling.
    294341It is a dynamic, non-local goto. If the raised exception is matched and
     
    309356@is_termination_exception@ at the call site.
    310357Through \CFA's trait system, the trait functions are implicitly passed into the
    311 throw code and the EHM.
     358throw code for use by the EHM.
    312359A new @defaultTerminationHandler@ can be defined in any scope to
    313 change the throw's behaviour (see below).
     360change the throw's behaviour when a handler is not found (see below).
    314361
    315362The throw copies the provided exception into managed memory to ensure
     
    321368% How to say propagation starts, its first sub-step is the search.
    322369Then propagation starts with the search. \CFA uses a ``first match" rule so
    323 matching is preformed with the copied exception as the search continues.
    324 It starts from the throwing function and proceeds towards base of the stack,
     370matching is performed with the copied exception as the search key.
     371It starts from the raise site and proceeds towards base of the stack,
    325372from callee to caller.
    326 At each stack frame, a check is made for resumption handlers defined by the
     373At each stack frame, a check is made for termination handlers defined by the
    327374@catch@ clauses of a @try@ statement.
    328375\begin{cfa}
     
    336383\end{cfa}
    337384When viewed on its own, a try statement simply executes the statements
    338 in \snake{GUARDED_BLOCK} and when those are finished,
     385in the \snake{GUARDED_BLOCK} and when those are finished,
    339386the try statement finishes.
    340387
     
    342389invoked functions, all the handlers in these statements are included in the
    343390search path.
    344 Hence, if a termination exception is raised these handlers may be matched
     391Hence, if a termination exception is raised, these handlers may be matched
    345392against the exception and may handle it.
    346393
    347394Exception matching checks the handler in each catch clause in the order
    348395they appear, top to bottom. If the representation of the raised exception type
    349 is the same or a descendant of @EXCEPTION_TYPE@$_i$ then @NAME@$_i$
     396is the same or a descendant of @EXCEPTION_TYPE@$_i$, then @NAME@$_i$
    350397(if provided) is
    351398bound to a pointer to the exception and the statements in @HANDLER_BLOCK@$_i$
     
    353400freed and control continues after the try statement.
    354401
    355 If no termination handler is found during the search then the default handler
    356 (\defaultTerminationHandler) visible at the raise statement is run.
    357 Through \CFA's trait system the best match at the raise statement will be used.
     402If no termination handler is found during the search, then the default handler
     403(\defaultTerminationHandler) visible at the raise statement is called.
     404Through \CFA's trait system the best match at the raise statement is used.
    358405This function is run and is passed the copied exception.
    359 If the default handler is run control continues after the raise statement.
     406If the default handler finishes, control continues after the raise statement.
    360407
    361408There is a global @defaultTerminationHandler@ that is polymorphic over all
    362409termination exception types.
    363 Since it is so general a more specific handler can be
    364 defined and is used for those types, effectively overriding the handler
    365 for a particular exception type.
    366410The global default termination handler performs a cancellation
    367 (see \vref{s:Cancellation}) on the current stack with the copied exception.
     411(as described in \vref{s:Cancellation})
     412on the current stack with the copied exception.
     413Since it is so general, a more specific handler can be defined,
     414overriding the default behaviour for the specific exception types.
    368415
    369416\subsection{Resumption}
    370417\label{s:Resumption}
    371418
    372 Resumption exception handling is less common than termination but is
     419Resumption exception handling is less familar form of exception handling,
     420but is
    373421just as old~\cite{Goodenough75} and is simpler in many ways.
    374422It is a dynamic, non-local function call. If the raised exception is
    375 matched a closure is taken from up the stack and executed,
     423matched, a closure is taken from up the stack and executed,
    376424after which the raising function continues executing.
    377425The common uses for resumption exceptions include
     
    379427function once the error is corrected, and
    380428ignorable events, such as logging where nothing needs to happen and control
    381 should always continue from the same place.
     429should always continue from the raise site.
     430
     431Except for the changes to fit into that pattern, resumption exception
     432handling is symmetric with termination exception handling, by design
     433(see \autoref{s:Termination}).
    382434
    383435A resumption raise is started with the @throwResume@ statement:
     
    386438\end{cfa}
    387439\todo{Decide on a final set of keywords and use them everywhere.}
    388 It works much the same way as the termination throw.
    389 The expression must return a reference to a resumption exception,
    390 where the resumption exception is any type that satisfies the trait
    391 @is_resumption_exception@ at the call site.
    392 The assertions from this trait are available to
    393 the exception system while handling the exception.
    394 
    395 At run-time, no exception copy is made.
    396 Resumption does not unwind the stack nor otherwise remove values from the
    397 current scope, so there is no need to manage memory to keep things in scope.
    398 
    399 The EHM then begins propagation. The search starts from the raise in the
    400 resuming function and proceeds towards the base of the stack,
    401 from callee to caller.
    402 At each stack frame, a check is made for resumption handlers defined by the
    403 @catchResume@ clauses of a @try@ statement.
     440It works much the same way as the termination raise, except the
     441type must satisfy the \snake{is_resumption_exception} that uses the
     442default handler: \defaultResumptionHandler.
     443This can be specialized for particular exception types.
     444
     445At run-time, no exception copy is made. Since
     446resumption does not unwind the stack nor otherwise remove values from the
     447current scope, there is no need to manage memory to keep the exception
     448allocated.
     449
     450Then propagation starts with the search,
     451following the same search path as termination,
     452from the raise site to the base of stack and top of try statement to bottom.
     453However, the handlers on try statements are defined by @catchResume@ clauses.
    404454\begin{cfa}
    405455try {
     
    411461}
    412462\end{cfa}
    413 % I wonder if there would be some good central place for this.
    414463Note that termination handlers and resumption handlers may be used together
    415464in a single try statement, intermixing @catch@ and @catchResume@ freely.
    416465Each type of handler only interacts with exceptions from the matching
    417466kind of raise.
    418 When a try statement is executed, it simply executes the statements in the
    419 @GUARDED_BLOCK@ and then finishes.
    420 
    421 However, while the guarded statements are being executed, including any
    422 invoked functions, all the handlers in these statements are included in the
    423 search path.
    424 Hence, if a resumption exception is raised these handlers may be matched
    425 against the exception and may handle it.
    426 
    427 Exception matching checks the handler in each catch clause in the order
    428 they appear, top to bottom. If the representation of the raised exception type
    429 is the same or a descendant of @EXCEPTION_TYPE@$_i$ then @NAME@$_i$
    430 (if provided) is bound to a pointer to the exception and the statements in
    431 @HANDLER_BLOCK@$_i$ are executed.
    432 If control reaches the end of the handler, execution continues after the
    433 the raise statement that raised the handled exception.
    434 
    435 Like termination, if no resumption handler is found during the search,
    436 the default handler (\defaultResumptionHandler) visible at the raise
    437 statement is called. It will use the best match at the raise sight according
    438 to \CFA's overloading rules. The default handler is
    439 passed the exception given to the raise. When the default handler finishes
    440 execution continues after the raise statement.
    441 
    442 There is a global \defaultResumptionHandler{} is polymorphic over all
    443 resumption exceptions and preforms a termination throw on the exception.
    444 The \defaultTerminationHandler{} can be overridden by providing a new
    445 function that is a better match.
     467Like @catch@ clauses, @catchResume@ clauses have no effect if an exception
     468is not raised.
     469
     470The matching rules are exactly the same as well.
     471The first major difference here is that after
     472@EXCEPTION_TYPE@$_i$ is matched and @NAME@$_i$ is bound to the exception,
     473@HANDLER_BLOCK@$_i$ is executed right away without first unwinding the stack.
     474After the block has finished running control jumps to the raise site, where
     475the just handled exception came from, and continues executing after it,
     476not after the try statement.
    446477
    447478\subsubsection{Resumption Marking}
    448479\label{s:ResumptionMarking}
    449480A key difference between resumption and termination is that resumption does
    450 not unwind the stack. A side effect that is that when a handler is matched
    451 and run it's try block (the guarded statements) and every try statement
     481not unwind the stack. A side effect is that, when a handler is matched
     482and run, its try block (the guarded statements) and every try statement
    452483searched before it are still on the stack. There presence can lead to
    453484the recursive resumption problem.
     485\todo{Is there a citation for the recursive resumption problem?}
    454486
    455487The recursive resumption problem is any situation where a resumption handler
     
    465497When this code is executed, the guarded @throwResume@ starts a
    466498search and matches the handler in the @catchResume@ clause. This
    467 call is placed on the stack above the try-block. The second raise then
    468 searches the same try block and puts another instance of the
     499call is placed on the stack above the try-block.
     500Now the second raise in the handler searches the same try block,
     501matches again and then puts another instance of the
    469502same handler on the stack leading to infinite recursion.
    470503
    471504While this situation is trivial and easy to avoid, much more complex cycles
    472505can form with multiple handlers and different exception types.
    473 
    474 To prevent all of these cases, a each try statement is ``marked" from the
    475 time the exception search reaches it to either when the exception is being
    476 handled completes the matching handler or when the search reaches the base
     506To prevent all of these cases, each try statement is ``marked" from the
     507time the exception search reaches it to either when a handler completes
     508handling that exception or when the search reaches the base
    477509of the stack.
    478510While a try statement is marked, its handlers are never matched, effectively
     
    486518for instance, marking just the handlers that caught the exception,
    487519would also prevent recursive resumption.
    488 However, these rules mirror what happens with termination.
    489 
    490 The try statements that are marked are the ones that would be removed from
    491 the stack if this was a termination exception, that is those on the stack
     520However, the rules selected mirrors what happens with termination,
     521so this reduces the amount of rules and patterns a programmer has to know.
     522
     523The marked try statements are the ones that would be removed from
     524the stack for a termination exception, \ie those on the stack
    492525between the handler and the raise statement.
    493526This symmetry applies to the default handler as well, as both kinds of
     
    523556        // Only handle IO failure for f3.
    524557}
    525 // Can't handle a failure relating to f2 here.
     558// Handle a failure relating to f2 further down the stack.
    526559\end{cfa}
    527560In this example the file that experienced the IO error is used to decide
     
    554587
    555588\subsection{Comparison with Reraising}
    556 A more popular way to allow handlers to match in more detail is to reraise
    557 the exception after it has been caught, if it could not be handled here.
    558 On the surface these two features seem interchangeable.
    559 
    560 If @throw;@ (no argument) starts a termination reraise,
    561 which is the same as a raise but reuses the last caught exception,
    562 then these two statements have the same behaviour:
     589In languages without conditional catch, that is no ability to match an
     590exception based on something other than its type, it can be mimicked
     591by matching all exceptions of the right type, checking any additional
     592conditions inside the handler and re-raising the exception if it does not
     593match those.
     594
     595Here is a minimal example comparing both patterns, using @throw;@
     596(no argument) to start a re-raise.
     597\begin{center}
     598\begin{tabular}{l r}
    563599\begin{cfa}
    564600try {
    565601    do_work_may_throw();
    566 } catch(exception_t * exc ; can_handle(exc)) {
     602} catch(exception_t * exc ;
     603                can_handle(exc)) {
    567604    handle(exc);
    568605}
    569 \end{cfa}
    570 
     606
     607
     608
     609\end{cfa}
     610&
    571611\begin{cfa}
    572612try {
    573613    do_work_may_throw();
    574 } catch(exception_t * exc) { 
     614} catch(exception_t * exc) {
    575615    if (can_handle(exc)) {
    576616        handle(exc);
     
    580620}
    581621\end{cfa}
    582 That is, they will have the same behaviour in isolation.
    583 Two things can expose differences between these cases.
    584 
    585 One is the existence of multiple handlers on a single try statement.
    586 A reraise skips all later handlers on this try statement but a conditional
    587 catch does not.
    588 Hence, if an earlier handler contains a reraise later handlers are
    589 implicitly skipped, with a conditional catch they are not.
    590 Still, they are equivalently powerful,
    591 both can be used two mimic the behaviour of the other,
    592 as reraise can pack arbitrary code in the handler and conditional catches
    593 can put arbitrary code in the predicate.
    594 % I was struggling with a long explanation about some simple solutions,
    595 % like repeating a condition on later handlers, and the general solution of
    596 % merging everything together. I don't think it is useful though unless its
    597 % for a proof.
    598 % https://en.cppreference.com/w/cpp/language/throw
    599 
    600 The question then becomes ``Which is a better default?"
    601 We believe that not skipping possibly useful handlers is a better default.
    602 If a handler can handle an exception it should and if the handler can not
    603 handle the exception then it is probably safer to have that explicitly
    604 described in the handler itself instead of implicitly described by its
    605 ordering with other handlers.
    606 % Or you could just alter the semantics of the throw statement. The handler
    607 % index is in the exception so you could use it to know where to start
    608 % searching from in the current try statement.
    609 % No place for the `goto else;` metaphor.
    610 
    611 The other issue is all of the discussion above assumes that the only
    612 way to tell apart two raises is the exception being raised and the remaining
    613 search path.
    614 This is not true generally, the current state of the stack can matter in
    615 a number of cases, even only for a stack trace after an program abort.
    616 But \CFA has a much more significant need of the rest of the stack, the
    617 default handlers for both termination and resumption.
    618 
    619 % For resumption it turns out it is possible continue a raise after the
    620 % exception has been caught, as if it hadn't been caught in the first place.
    621 This becomes a problem combined with the stack unwinding used in termination
    622 exception handling.
    623 The stack is unwound before the handler is installed, and hence before any
    624 reraises can run. So if a reraise happens the previous stack is gone,
    625 the place on the stack where the default handler was supposed to run is gone,
    626 if the default handler was a local function it may have been unwound too.
    627 There is no reasonable way to restore that information, so the reraise has
    628 to be considered as a new raise.
    629 This is the strongest advantage conditional catches have over reraising,
    630 they happen before stack unwinding and avoid this problem.
    631 
    632 % The one possible disadvantage of conditional catch is that it runs user
    633 % code during the exception search. While this is a new place that user code
    634 % can be run destructors and finally clauses are already run during the stack
    635 % unwinding.
     622\end{tabular}
     623\end{center}
     624At first glance catch-and-reraise may appear to just be a quality of life
     625feature, but there are some significant differences between the two
     626stratagies.
     627
     628A simple difference that is more important for \CFA than many other languages
     629is that the raise site changes, with a re-raise but does not with a
     630conditional catch.
     631This is important in \CFA because control returns to the raise site to run
     632the per-site default handler. Because of this only a conditional catch can
     633allow the original raise to continue.
     634
     635The more complex issue comes from the difference in how conditional
     636catches and re-raises handle multiple handlers attached to a single try
     637statement. A conditional catch will continue checking later handlers while
     638a re-raise will skip them.
     639If the different handlers could handle some of the same exceptions,
     640translating a try statement that uses one to use the other can quickly
     641become non-trivial:
     642
     643\noindent
     644Original, with conditional catch:
     645\begin{cfa}
     646...
     647} catch (an_exception * e ; check_a(e)) {
     648        handle_a(e);
     649} catch (exception_t * e ; check_b(e)) {
     650        handle_b(e);
     651}
     652\end{cfa}
     653Translated, with re-raise:
     654\begin{cfa}
     655...
     656} catch (exception_t * e) {
     657        an_exception * an_e = (virtual an_exception *)e;
     658        if (an_e && check_a(an_e)) {
     659                handle_a(an_e);
     660        } else if (check_b(e)) {
     661                handle_b(e);
     662        } else {
     663                throw;
     664        }
     665}
     666\end{cfa}
     667(There is a simpler solution if @handle_a@ never raises exceptions,
     668using nested try statements.)
     669
     670% } catch (an_exception * e ; check_a(e)) {
     671%     handle_a(e);
     672% } catch (exception_t * e ; !(virtual an_exception *)e && check_b(e)) {
     673%     handle_b(e);
     674% }
    636675%
    637 % https://www.cplusplus.com/reference/exception/current_exception/
    638 %   `exception_ptr current_exception() noexcept;`
    639 % https://www.python.org/dev/peps/pep-0343/
     676% } catch (an_exception * e)
     677%   if (check_a(e)) {
     678%     handle_a(e);
     679%   } else throw;
     680% } catch (exception_t * e)
     681%   if (check_b(e)) {
     682%     handle_b(e);
     683%   } else throw;
     684% }
     685In similar simple examples translating from re-raise to conditional catch
     686takes less code but it does not have a general trivial solution either.
     687
     688So, given that the two patterns do not trivially translate into each other,
     689it becomes a matter of which on should be encouraged and made the default.
     690From the premise that if a handler that could handle an exception then it
     691should, it follows that checking as many handlers as possible is preferred.
     692So conditional catch and checking later handlers is a good default.
    640693
    641694\section{Finally Clauses}
     
    669722
    670723Not all languages with unwinding have finally clauses. Notably \Cpp does
    671 without it as descructors, and the RAII design pattern, serve a similar role.
    672 Although destructors and finally clauses can be used in the same cases,
     724without it as destructors, and the RAII design pattern, serve a similar role.
     725Although destructors and finally clauses can be used for the same cases,
    673726they have their own strengths, similar to top-level function and lambda
    674727functions with closures.
    675 Destructors take more work for their first use, but if there is clean-up code
    676 that needs to be run every time a type is used they soon become much easier
    677 to set-up.
     728Destructors take more work to create, but if there is clean-up code
     729that needs to be run every time a type is used, they are much easier
     730to set-up for each use. % It's automatic.
    678731On the other hand finally clauses capture the local context, so is easy to
    679732use when the clean-up is not dependent on the type of a variable or requires
    680733information from multiple variables.
    681 % To Peter: I think these are the main points you were going for.
    682734
    683735\section{Cancellation}
     
    692744raise, this exception is not used in matching only to pass information about
    693745the cause of the cancellation.
    694 (This also means matching cannot fail so there is no default handler.)
     746Finally, as no handler is provided, there is no default handler.
    695747
    696748After @cancel_stack@ is called the exception is copied into the EHM's memory
     
    703755After the main stack is unwound there is a program-level abort.
    704756
    705 There are two reasons for these semantics.
    706 The first is that it had to do this abort.
    707 in a sequential program as there is nothing else to notify and the simplicity
    708 of keeping the same behaviour in sequential and concurrent programs is good.
    709 Also, even in concurrent programs there may not currently be any other stacks
    710 and even if other stacks do exist, main has no way to know where they are.
     757The first reason for this behaviour is for sequential programs where there
     758is only one stack, and hence to stack to pass information to.
     759Second, even in concurrent programs, the main stack has no dependency
     760on another stack and no reliable way to find another living stack.
     761Finally, keeping the same behaviour in both sequential and concurrent
     762programs is simple and easy to understand.
    711763
    712764\paragraph{Thread Stack}
     
    738790
    739791With explicit join and a default handler that triggers a cancellation, it is
    740 possible to cascade an error across any number of threads, cleaning up each
     792possible to cascade an error across any number of threads,
     793alternating between the resumption (possibly termination) and cancellation,
     794cleaning up each
    741795in turn, until the error is handled or the main thread is reached.
    742796
     
    751805caller's context and passes it to the internal report.
    752806
    753 A coroutine knows of two other coroutines, its starter and its last resumer.
     807A coroutine only knows of two other coroutines,
     808its starter and its last resumer.
    754809The starter has a much more distant connection, while the last resumer just
    755810(in terms of coroutine state) called resume on this coroutine, so the message
     
    757812
    758813With a default handler that triggers a cancellation, it is possible to
    759 cascade an error across any number of coroutines, cleaning up each in turn,
     814cascade an error across any number of coroutines,
     815alternating between the resumption (possibly termination) and cancellation,
     816cleaning up each in turn,
    760817until the error is handled or a thread stack is reached.
Note: See TracChangeset for help on using the changeset viewer.