Changeset 8483c39a


Ignore:
Timestamp:
Apr 6, 2021, 9:16:52 PM (3 years ago)
Author:
Peter A. Buhr <pabuhr@…>
Branches:
ADT, arm-eh, ast-experimental, enum, forall-pointer-decay, jacob/cs343-translation, master, new-ast-unique-expr, pthread-emulation, qualifiedEnum
Children:
e07b589
Parents:
7039ab9
Message:

proofread chapter features

File:
1 edited

Legend:

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

    r7039ab9 r8483c39a  
    33This chapter covers the design and user interface of the \CFA
    44exception-handling mechanism (EHM). % or exception system.
     5While an EHM is free to add many features,
     6the following overview covers the basic features that all EHMs use, but it is not an
     7exhaustive list of everything an EHM can do.
    58
    69% We should cover what is an exception handling mechanism and what is an
     
    912\paragraph{Raise / Handle}
    1013An exception operation has two main parts: raise and handle.
    11 These are the two parts that the user will write themselves and so
    12 might be the only two pieces of the EHM that have any syntax.
    1314These terms are sometimes also known as throw and catch but this work uses
    1415throw/catch as a particular kind of raise/handle.
     16These are the two parts a programmer writes and so
     17are the only two pieces of the EHM that have language syntax.
    1518
    1619\subparagraph{Raise}
    17 The raise is the starting point for exception handling and usually how
    18 Some well known examples include the throw statements of \Cpp and Java and
    19 the raise statement from Python.
    20 
    21 For this overview a raise does nothing more kick off the handling of an
    22 exception, which is called raising the exception. This is inexact but close
    23 enough for the broad strokes of the overview.
     20The raise is the starting point for exception handling and usually how \PAB{This sentence is cut off.}
     21Some well known examples include the @throw@ statement of \Cpp and Java and
     22the \lstinline[language=Python]{raise} statement from Python.
     23
     24For this overview, a raise starts the handling of an
     25exception, which is called \newterm{raising} an exception. This simple description is sufficient
     26for the overview.
    2427
    2528\subparagraph{Handle}
    26 The purpose of most exception operations is to run some sort of handler that
    27 contains user code.
    28 The try statement of \Cpp illistrates the common features
    29 Handlers have three common features: a region of code they apply to, an
    30 exception label that describes what exceptions they handle and code to run
    31 when they handle an exception.
    32 Each handler can handle exceptions raised in that region that match their
    33 exception label. Different EHMs will have different rules to pick a handler
    34 if multipe handlers could be used such as ``best match" or ``first found".
     29The purpose of raising an exception is to run user code to address (handle) the
     30issue found at the raise point.
     31The @try@ statement of \Cpp illustrates a common approach for specifying multiple handlers.
     32A handler has three common features: the scope in which it applies, an
     33exception label that describes what exceptions it can handle, and code to run
     34that deals with the raised issue.
     35Each handler can handle exceptions raised in the region matching its
     36exception label. For multiple matches, different EHMs have different rules for matching an exception to a handler label,
     37such as ``best match" or ``first found".
    3538
    3639\paragraph{Propagation}
    37 After an exception is raised comes what is usually the biggest step for the
    38 EHM, finding and setting up the handler. This can be broken up into three
    39 different tasks: searching for a handler, matching against the handler and
    40 installing the handler.
    41 
    42 First the EHM must search for possible handlers that could be used to handle
    43 the exception. Searching is usually independent of the exception that was
    44 thrown and instead depends on the call stack, the current function, its caller
     40After an exception is raised, comes the most complex step for the
     41EHM: finding and setting up the handler. This propagation of exception from raise to handler can be broken up into three
     42different tasks: searching, matching, and
     43installing the handler so it can execute.
     44
     45\subparagraph{Searching}
     46The EHM searches for possible handlers that can be used to handle
     47the exception. Searching is usually independent of the exception that is
     48thrown and instead depends on the call stack: current function, its caller
    4549and repeating down the stack.
    4650
    47 Second it much match the exception with each handler to see which one is the
    48 best match and hence which one should be used to handle the exception.
    49 In languages where the best match is the first match these two are often
    50 intertwined, a match check is preformed immediately after the search finds
     51\subparagraph{Matching}
     52For each handler found, it compares the raised exception with the handler label to see which one is the
     53best match, and hence, which one should be used to handle the exception.
     54In languages where the best match is the first match, these two steps are often
     55intertwined, \ie a match check is performed immediately after the search finds
    5156a possible handler.
    5257
    53 Third, after a handler is chosen it must be made ready to run.
    54 What this actually involves can vary widely to fit with the rest of the
    55 design of the EHM. The installation step might be trivial or it could be
     58\subparagraph{Installing}
     59After a handler is chosen, it must be made ready to run.
     60This step varies widely to fit with the rest of the
     61design of the EHM. The installation step might be trivial or it can be
    5662the most expensive step in handling an exception. The latter tends to be the
    5763case when stack unwinding is involved.
    58 
    59 As an alternate third step if no appropriate handler is found then some sort
    60 of recovery has to be preformed. This is only required with unchecked
    61 exceptions as checked exceptions can promise that a handler is found. It also
    62 is also installing a handler but it is a special default that may be
     64An alternate action occurs if no appropriate handler is found, then some implicit action
     65is performed. This step is only required with unchecked
     66exceptions as checked exceptions (Java) promise a handler is always found. The implicit action
     67also installs a handler but it is a default handle that may be
    6368installed differently.
    6469
    6570\subparagraph{Hierarchy}
    66 In \CFA the EHM uses a hierarchial system to organise its exceptions.
    67 This stratagy is borrowed from object-orientated languages where the
     71Some EHM (\CFA, Java) organize exceptions in a hierarchical structure.
     72This strategy is borrowed from object-orientated languages where the
    6873exception hierarchy is a natural extension of the object hierarchy.
    6974
    7075Consider the following hierarchy of exceptions:
    7176\begin{center}
    72 \setlength{\unitlength}{4000sp}%
    73 \begin{picture}(1605,612)(2011,-1951)
    74 \put(2100,-1411){\vector(1, 0){225}}
    75 \put(3450,-1411){\vector(1, 0){225}}
    76 \put(3550,-1411){\line(0,-1){225}}
    77 \put(3550,-1636){\vector(1, 0){150}}
    78 \put(3550,-1636){\line(0,-1){225}}
    79 \put(3550,-1861){\vector(1, 0){150}}
    80 \put(2025,-1490){\makebox(0,0)[rb]{\LstBasicStyle{exception}}}
    81 \put(2400,-1460){\makebox(0,0)[lb]{\LstBasicStyle{arithmetic}}}
    82 \put(3750,-1460){\makebox(0,0)[lb]{\LstBasicStyle{underflow}}}
    83 \put(3750,-1690){\makebox(0,0)[lb]{\LstBasicStyle{overflow}}}
    84 \put(3750,-1920){\makebox(0,0)[lb]{\LstBasicStyle{zerodivide}}}
    85 \end{picture}%
     77\input{exceptionHierarchy}
    8678\end{center}
    87 
    8879A handler labelled with any given exception can handle exceptions of that
    8980type or any child type of that exception. The root of the exception hierarchy
    90 (here \texttt{exception}) acts as a catch-all, leaf types catch single types
     81(here \lstinline[language=C++]{exception}) acts as a catch-all, leaf types catch single types
    9182and the exceptions in the middle can be used to catch different groups of
    9283related exceptions.
    9384
    9485This system has some notable advantages, such as multiple levels of grouping,
    95 the ability for libraries to add new exception types and the isolation
    96 between different sub-hierarchies. So the design was adapted for a
     86the ability for libraries to add new exception types, and the isolation
     87between different sub-hierarchies. This capability had to be adapted for \CFA, which is a
    9788non-object-orientated language.
    9889
     
    10091
    10192\paragraph{Completion}
    102 After the handler has finished the entire exception operation has to complete
    103 and continue executing somewhere else. This step is usually very simple
    104 both logically and in its implementation as the installation of the handler
    105 usually does the heavy lifting.
    106 
    107 The EHM can return control to many different places.
    108 However, the most common is after the handler definition and the next most
    109 common is after the raise.
     93After the handler has returned, the entire exception operation has to complete
     94and continue executing somewhere. This step is usually simple,
     95both logically and in its implementation, as the installation of the handler
     96usually does the preparation.
     97The EHM can return control to different places,
     98where the most common are after the handler definition or after the raise.
    11099
    111100\paragraph{Communication}
    112 For effective exception handling, additional information is usually required
    113 as this base model only communicates the exception's identity. Common
    114 additional methods of communication are putting fields on an exception and
    115 allowing a handler to access the lexical scope it is defined in (usually
    116 a function's local variables).
    117 
    118 \paragraph{Other Features}
    119 Any given exception handling mechanism is free at add other features on top
    120 of this. This is an overview of the base that all EHMs use but it is not an
    121 exaustive list of everything an EHM can do.
     101For effective exception handling, additional information is usually passed from the raise,
     102where this basic model only communicates the exception's identity. A common
     103methods for communication is putting fields into an exception and
     104allowing a handler to access these fields via an exception instance in the handler's scope.
    122105
    123106\section{Virtuals}
    124 Virtual types and casts are not part of the exception system nor are they
    125 required for an exception system. But an object-oriented style hierarchy is a
    126 great way of organizing exceptions so a minimal virtual system has been added
    127 to \CFA.
     107Virtual types and casts are not part of an EHM nor are they
     108required for an EHM. But as pointed out, an object-oriented-style hierarchy is an
     109excellent way of organizing exceptions. Hence, a minimal virtual system has been added
     110to \CFA to support hierarchical exceptions.
    128111
    129112The virtual system supports multiple ``trees" of types. Each tree is
    130113a simple hierarchy with a single root type. Each type in a tree has exactly
    131 one parent - except for the root type which has zero parents - and any
     114one parent -- except for the root type with zero parents -- and any
    132115number of children.
    133116Any type that belongs to any of these trees is called a virtual type.
     
    135118% A type's ancestors are its parent and its parent's ancestors.
    136119% The root type has no ancestors.
    137 % A type's decendents are its children and its children's decendents.
    138 
    139 Every virtual type also has a list of virtual members. Children inherit
    140 their parent's list of virtual members but may add new members to it.
    141 It is important to note that these are virtual members, not virtual methods.
    142 However as function pointers are allowed they can be used to mimic virtual
    143 methods as well.
    144 
    145 The unique id for the virtual type and all the virtual members are combined
    146 into a virtual table type. Each virtual type has a pointer to a virtual table
     120% A type's descendents are its children and its children's descendents.
     121
     122Every virtual type has a list of virtual members. Children inherit
     123their parent's virtual members but may add new members to it.
     124It is important to note that these are virtual members, not virtual methods of an object type.
     125However, as \CFA has function pointers, they can be used to mimic virtual
     126methods.
     127
     128Each virtual type has a unique id.
     129The unique id for the virtual type and all its virtual members are combined
     130into a virtual-table type. Each virtual type has a pointer to a virtual table
    147131as a hidden field.
    148132
    149 Up until this point the virtual system is a lot like ones found in object-
    150 orientated languages but this where they diverge. Objects encapsulate a
     133Up to this point, a virtual system is similar to ones found in object-oriented
     134languages but this is where \CFA diverges. Objects encapsulate a
    151135single set of behaviours in each type, universally across the entire program,
    152 and indeed all programs that use that type definition. In this sense the
     136and indeed all programs that use that type definition. In this sense, the
    153137types are ``closed" and cannot be altered.
    154 
    155 However in \CFA types do not encapsulate any behaviour. Traits are local and
    156 types can begin to statify a trait, stop satifying a trait or satify the same
    157 trait in a different way with each new definition. In this sense they are
    158 ``open" as they can change at any time. This means it is implossible to pick
    159 a single set of functions that repersent the type.
    160 
    161 So we don't try to have a single value. The user can define virtual tables
    162 which are filled in at their declaration and given a name. Anywhere you can
    163 see that name you can use that virtual table; even if it is defined locally
    164 inside a function, although in that case you must respect its lifetime.
    165 
    166 An object of a virtual type is ``bound" to a virtual table instance which
     138However, \CFA types do not encapsulate any behaviour. Instead, traits are used and
     139types can satisfy a trait, stop satisfying a trait, or satisfy the same
     140trait in a different way depending on the lexical context. In this sense, the types are
     141``open" as their behaviour can change in different scopes. This capability means it is impossible to pick
     142a single set of functions that represent the type's virtual members.
     143
     144Hence, \CFA does not have a single virtual table for a type. A user can define different virtual tables,
     145which are filled in at their declaration and given a name.
     146That name is used as the virtual table, even if it is defined locally
     147inside a function, although lifetime issues must be considered.
     148Specifically, an object of a virtual type is ``bound" to a virtual table instance, which
    167149sets the virtual members for that object. The virtual members can be accessed
    168150through the object.
     
    178160\Cpp syntax for special casts. Both the type of @EXPRESSION@ and @TYPE@ must be
    179161a pointer to a virtual type.
    180 The cast dynamically checks if the @EXPRESSION@ type is the same or a sub-type
     162The cast dynamically checks if the @EXPRESSION@ type is the same or a subtype
    181163of @TYPE@, and if true, returns a pointer to the
    182164@EXPRESSION@ object, otherwise it returns @0p@ (null pointer).
     
    196178\end{cfa}
    197179The trait is defined over two types, the exception type and the virtual table
    198 type. This should be one-to-one, each exception type has only one virtual
     180type. These type should have a one-to-one relationship: each exception type has only one virtual
    199181table type and vice versa. The only assertion in the trait is
    200182@get_exception_vtable@, which takes a pointer of the exception type and
    201 returns a reference to the virtual table type instance.
     183returns a reference to the virtual-table type-instance.
    202184
    203185The function @get_exception_vtable@ is actually a constant function.
    204 Regardless of the value passed in (including the null pointer) it should
    205 return a reference to the virtual table instance for that type.
    206 The reason it is a function instead of a constant is that it make type
    207 annotations easier to write as you can use the exception type instead of the
    208 virtual table type; which usually has a mangled name.
     186Regardless of the value passed in (including the null pointer) it
     187returns a reference to the virtual-table instance for that type.
     188The reason it is a function instead of a constant is to make type
     189annotations easier to write using the exception type rather than the
     190virtual-table type, which usually has a mangled name because it is an internal component of the EHM.
    209191% Also \CFA's trait system handles functions better than constants and doing
    210192% it this way reduce the amount of boiler plate we need.
     
    212194% I did have a note about how it is the programmer's responsibility to make
    213195% sure the function is implemented correctly. But this is true of every
    214 % similar system I know of (except Agda's I guess) so I took it out.
    215 
    216 There are two more traits for exceptions @is_termination_exception@ and
    217 @is_resumption_exception@. They are defined as follows:
    218 
     196% similar system I know of (except Ada's I guess) so I took it out.
     197
     198There are two more exception traits defined as follows:
    219199\begin{cfa}
    220200trait is_termination_exception(
     
    228208};
    229209\end{cfa}
    230 
    231 In other words they make sure that a given type and virtual type is an
    232 exception and defines one of the two default handlers. These default handlers
    233 are used in the main exception handling operations \see{Exception Handling}
    234 and their use will be detailed there.
    235 
    236 However all three of these traits can be tricky to use directly.
    237 There is a bit of repetition required but
    238 the largest issue is that the virtual table type is mangled and not in a user
    239 facing way. So there are three macros that can be used to wrap these traits
    240 when you need to refer to the names:
     210These traits ensure a given type and virtual type are an
     211exception type and defines one of the two default handlers. The default handlers
     212are used in the main exception-handling operations and discussed in detail in \VRef{s:ExceptionHandling}.
     213
     214However, all three of these traits are tricky to use directly.
     215While there is a bit of repetition required,
     216the largest issue is that the virtual-table type is mangled and not in a user
     217facing way. So three macros are provided to wrap these traits
     218to simplify referring to the names:
    241219@IS_EXCEPTION@, @IS_TERMINATION_EXCEPTION@ and @IS_RESUMPTION_EXCEPTION@.
    242220
    243 All take one or two arguments. The first argument is the name of the
    244 exception type. Its unmangled and mangled form are passed to the trait.
     221These macros take one or two arguments. The first argument is the name of the
     222exception type. The macro passes the unmangled and mangled form to the trait.
    245223The second (optional) argument is a parenthesized list of polymorphic
    246 arguments. This argument should only with polymorphic exceptions and the
    247 list will be passed to both types.
    248 In the current set-up the base name and the polymorphic arguments have to
     224arguments. This argument is only used with polymorphic exceptions and the
     225list is passed to both types.
     226In the current set-up, the base name and the polymorphic arguments have to
    249227match so these macros can be used without losing flexibility.
    250228
     
    252230defined arithmetic exception:
    253231\begin{cfa}
    254 forall(Num | IS_EXCEPTION(Arithmetic, (Num)))
     232forall(Num | @IS_EXCEPTION(Arithmetic, Num)@)
    255233void some_math_function(Num & left, Num & right);
    256234\end{cfa}
     235where the function may raise exception @Arithmetic@ or any of its decedents.
    257236
    258237\section{Exception Handling}
    259 \CFA provides two kinds of exception handling, termination and resumption.
    260 These twin operations are the core of the exception handling mechanism and
    261 are the reason for the features of exceptions.
    262 This section will cover the general patterns shared by the two operations and
    263 then go on to cover the details each individual operation.
    264 
    265 Both operations follow the same set of steps to do their operation. They both
    266 start with the user preforming a throw on an exception.
    267 Then there is the search for a handler, if one is found than the exception
    268 is caught and the handler is run. After that control returns to normal
    269 execution.
    270 
    271 If the search fails a default handler is run and then control
    272 returns to normal execution immediately. That is where the default handlers
    273 @defaultTermiationHandler@ and @defaultResumptionHandler@ are used.
     238\label{s:ExceptionHandling}
     239\CFA provides two kinds of exception handling: termination and resumption.
     240These twin mechanisms are the core of the \CFA EHM and
     241multiple features are provided to support them.
     242This section covers the general patterns shared by the two kinds of exceptions and
     243then covers the individual detail operations.
     244
     245Both mechanisms follow the same set of steps to do their operations. Both
     246start with the user performing an exception raise.
     247Then there is the handler search. If one is found, than the exception
     248is caught and the handler is run. When the handler returns, control returns to an
     249location appropriate for each kind of exception.
     250
     251\begin{sloppypar}
     252If the search fails, an appropriate default handler, @defaultTermiationHandler@
     253or @defaultResumptionHandler@, is run and  control returns to the
     254appropriate location.
     255\end{sloppypar}
    274256
    275257\subsection{Termination}
    276258\label{s:Termination}
    277 
    278 Termination handling is more familiar kind and used in most programming
     259Termination handling is familiar and used in most programming
    279260languages with exception handling.
    280 It is dynamic, non-local goto. If a throw is successful then the stack will
    281 be unwound and control will (usually) continue in a different function on
    282 the call stack. They are commonly used when an error has occurred and recovery
    283 is impossible in the current function.
     261It is a dynamic, non-local goto. The raise starts searching, and if matched and handled, the stack is
     262unwound and control (usually) continues in the function on
     263the call stack containing the handler. Terminate is commonly used for an error where recovery
     264is impossible in the function performing the raise.
    284265
    285266% (usually) Control can continue in the current function but then a different
    286267% control flow construct should be used.
    287268
    288 A termination throw is started with the @throw@ statement:
     269A termination raise is started with the @throw@ statement:
    289270\begin{cfa}
    290271throw EXPRESSION;
    291272\end{cfa}
    292273The expression must return a reference to a termination exception, where the
    293 termination exception is any type that satisfies @is_termination_exception@
    294 at the call site.
    295 Through \CFA's trait system the functions in the traits are passed into the
    296 throw code. A new @defaultTerminationHandler@ can be defined in any scope to
    297 change the throw's behavior (see below).
    298 
    299 The throw will copy the provided exception into managed memory. It is the
    300 user's responsibility to ensure the original exception is cleaned up if the
    301 stack is unwound (allocating it on the stack should be sufficient).
    302 
    303 Then the exception system searches the stack using the copied exception.
    304 It starts starts from the throw and proceeds to the base of the stack,
     274termination exception is any type that satisfies trait
     275@is_termination_exception@ at the call site.  Through \CFA's trait system, the
     276trait functions are implicitly passed into the hidden throw code and available
     277to the exception system while handling the exception. A new
     278@defaultTerminationHandler@ can be defined in any scope to change the throw's
     279unhandled behaviour (see below).
     280
     281The throw must copy the provided exception into managed memory because the stack is unwounded.
     282The lifetime of the exception copy is managed by the exception runtime.
     283It is the user's responsibility to ensure the original exception is cleaned up, where allocating it on the unwound stack is sufficient.
     284
     285The exception search walks the stack matching with the copied exception.
     286It starts from the throwing function and proceeds to the base of the stack,
    305287from callee to caller.
    306 At each stack frame, a check is made for resumption handlers defined by the
     288At each stack frame, a check is made for termination handlers defined by the
    307289@catch@ clauses of a @try@ statement.
    308290\begin{cfa}
    309291try {
    310292        GUARDED_BLOCK
    311 } catch (EXCEPTION_TYPE$\(_1\)$ * NAME$\(_1\)$) {
     293} catch (EXCEPTION_TYPE$\(_1\)$ [* NAME$\(_1\)$]) {
    312294        HANDLER_BLOCK$\(_1\)$
    313 } catch (EXCEPTION_TYPE$\(_2\)$ * NAME$\(_2\)$) {
     295} catch (EXCEPTION_TYPE$\(_2\)$ [* NAME$\(_2\)$]) {
    314296        HANDLER_BLOCK$\(_2\)$
    315297}
    316298\end{cfa}
    317 When viewed on its own a try statement will simply execute the statements in
    318 @GUARDED_BLOCK@ and when those are finished the try statement finishes.
    319 
    320 However, while the guarded statements are being executed, including any
    321 functions they invoke, all the handlers following the try block are now
    322 or any functions invoked from those
    323 statements, throws an exception, and the exception
    324 is not handled by a try statement further up the stack, the termination
    325 handlers are searched for a matching exception type from top to bottom.
    326 
    327 Exception matching checks the representation of the thrown exception-type is
    328 the same or a descendant type of the exception types in the handler clauses. If
    329 it is the same of a descendant of @EXCEPTION_TYPE@$_i$ then @NAME@$_i$ is
     299When viewed on its own, a @try@ statement with @catch@ clauses simply executes the statements in
     300the @GUARDED_BLOCK@, and when those are finished, the try statement finishes.
     301
     302However, while the guarded statements are being executed, including any invoked
     303functions, a termination exception may be thrown. If that exception is not handled by a try
     304statement further up the stack, the handlers following the try block are now
     305searched for a matching termination exception-type from top to bottom.
     306
     307Exception matching checks each @catch@ clasue from top to bottom, if the representation of the thrown exception-type is
     308the same or a descendant type of the exception types in the @catch@ clauses. If
     309it is the same or a descendant of @EXCEPTION_TYPE@$_i$, then the optional @NAME@$_i$ is
    330310bound to a pointer to the exception and the statements in @HANDLER_BLOCK@$_i$
    331311are executed. If control reaches the end of the handler, the exception is
    332 freed and control continues after the try statement.
    333 
    334 If no handler is found during the search then the default handler is run.
    335 Through \CFA's trait system the best match at the throw sight will be used.
    336 This function is run and is passed the copied exception. After the default
    337 handler is run control continues after the throw statement.
    338 
    339 There is a global @defaultTerminationHandler@ that cancels the current stack
    340 with the copied exception. However it is generic over all exception types so
    341 new default handlers can be defined for different exception types and so
    342 different exception types can have different default handlers.
     312freed and control continues after the @try@ statement.
     313
     314If no termination handler is found during the search, the default termination
     315handler visible at the raise is called.  Through \CFA's trait-system the best
     316default-handler match at the throw sight is used.  This function is
     317passed the copied exception given to the raise. After the default handler is
     318run, control continues after the @throw@ statement.
     319
     320There is a global @defaultTerminationHandler@ function that that is polymorphic
     321over all exception types allowing new default handlers to be defined for
     322different exception types and so different exception types can have different
     323default handlers.  The global default termination-handler performs a
     324cancellation \see{\VRef{s:Cancellation}} on the current stack with the copied
     325exception.
    343326
    344327\subsection{Resumption}
    345328\label{s:Resumption}
    346 
    347 Resumption exception handling is a less common form than termination but is
    348 just as old~\cite{Goodenough75} and is in some sense simpler.
    349 It is a dynamic, non-local function call. If the throw is successful a
    350 closure will be taken from up the stack and executed, after which the throwing
    351 function will continue executing.
    352 These are most often used when an error occurred and if the error is repaired
     329Resumption exception-handling is a less common counterpart to termination but is
     330just as old~\cite{Goodenough75} and is simpler to understand.
     331It is a dynamic, non-local function call (like Lisp). If the throw is successful, a
     332closure is taken from up the stack and executed, after which the throwing
     333function continues executing.
     334Resumption is used when an error occurred, and if the error is repaired,
    353335then the function can continue.
    354336
     337An alternative approach is explicitly passing fixup functions with local
     338closures up the stack to be called when an error occurs. However, fixup
     339functions significantly expand the parameters list of functions, even when the
     340fixup function is not used by a function but must be passed to other called
     341functions.
     342
    355343A resumption raise is started with the @throwResume@ statement:
    356344\begin{cfa}
    357345throwResume EXPRESSION;
    358346\end{cfa}
    359 The semantics of the @throwResume@ statement are like the @throw@, but the
    360 expression has return a reference a type that satisfies the trait
    361 @is_resumption_exception@. The assertions from this trait are available to
     347Like termination, the expression must return a reference to a resumption
     348exception, where the resumption exception is any type that satisfies the trait
     349@is_termination_exception@ at the call site.
     350The assertions for this trait are available to
    362351the exception system while handling the exception.
    363352
    364 At run-time, no copies are made. As the stack is not unwound the exception and
    365 any values on the stack will remain in scope while the resumption is handled.
    366 
    367 Then the exception system searches the stack using the provided exception.
    368 It starts starts from the throw and proceeds to the base of the stack,
     353At runtime, no exception copy is made, as the stack is not unwound. Hence, the exception and
     354any values on the stack remain in scope while the resumption is handled.
     355
     356The exception searches walks the stack matching with the provided exception.
     357It starts from the resuming function and proceeds to the base of the stack,
    369358from callee to caller.
    370359At each stack frame, a check is made for resumption handlers defined by the
     
    373362try {
    374363        GUARDED_BLOCK
    375 } catchResume (EXCEPTION_TYPE$\(_1\)$ * NAME$\(_1\)$) {
     364} catchResume (EXCEPTION_TYPE$\(_1\)$ [* NAME$\(_1\)$]) {
    376365        HANDLER_BLOCK$\(_1\)$
    377 } catchResume (EXCEPTION_TYPE$\(_2\)$ * NAME$\(_2\)$) {
     366} catchResume (EXCEPTION_TYPE$\(_2\)$ [* NAME$\(_2\)$]) {
    378367        HANDLER_BLOCK$\(_2\)$
    379368}
    380369\end{cfa}
    381 If the handlers are not involved in a search this will simply execute the
    382 @GUARDED_BLOCK@ and then continue to the next statement.
    383 Its purpose is to add handlers onto the stack.
    384 (Note, termination and resumption handlers may be intermixed in a @try@
    385 statement but the kind of throw must be the same as the handler for it to be
    386 considered as a possible match.)
    387 
    388 If a search for a resumption handler reaches a try block it will check each
    389 @catchResume@ clause, top-to-bottom.
    390 At each handler if the thrown exception is or is a child type of
    391 @EXCEPTION_TYPE@$_i$ then the a pointer to the exception is bound to
    392 @NAME@$_i$ and then @HANDLER_BLOCK@$_i$ is executed. After the block is
    393 finished control will return to the @throwResume@ statement.
    394 
    395 Like termination, if no resumption handler is found, the default handler
    396 visible at the throw statement is called. It will use the best match at the
    397 call sight according to \CFA's overloading rules. The default handler is
    398 passed the exception given to the throw. When the default handler finishes
    399 execution continues after the throw statement.
    400 
    401 There is a global @defaultResumptionHandler@ is polymorphic over all
    402 termination exceptions and preforms a termination throw on the exception.
     370Termination and resumption handlers may be intermixed in a @try@
     371statement but the kind of throw must match with kind of handler for it to be
     372considered as a possible match.
     373Like termination, when viewed on its own, a @try@ statement with
     374@catchResume@ clauses simply executes the statements in the @GUARDED_BLOCK@,
     375and when those are finished, the try statement finishes.
     376
     377However, while the guarded statements are being executed, including any invoked
     378functions, a resumption exception may be thrown. If that exception is not handled by a try
     379statement further up the stack, the handlers following the try block are now
     380searched for a matching resumption exception-type from top to bottom.
     381
     382Like termination, exception matching checks each @catch@ clasue from top to bottom, if the representation of the thrown exception-type is
     383the same or a descendant type of the exception types in the @catchResume@ clauses. If
     384it is the same or a descendant of @EXCEPTION_TYPE@$_i$, then the optional @NAME@$_i$ is
     385bound to a pointer to the exception and the statements in @HANDLER_BLOCK@$_i$
     386are executed. If control reaches the end of the handler, the exception is
     387freed and control continues after the @throwResume@ statement.
     388
     389Like termination, if no resumption handler is found during the search, the
     390default resumption handler visible at the raise is called, which is the best
     391match at the according to \CFA's overloading rules. This function is passed the
     392exception given to the raise. After the default handler is run, execution
     393continues after the @throwResume@ statement.
     394
     395There is a global @defaultResumptionHandler@ that is polymorphic over all
     396resumption and preforms a termination throw on the exception.
    403397The @defaultTerminationHandler@ for that throw is matched at the original
    404398throw statement (the resumption @throwResume@) and it can be customized by
    405399introducing a new or better match as well.
    406400
    407 % \subsubsection?
    408 
     401\subsection{Resumption Marking}
    409402A key difference between resumption and termination is that resumption does
    410 not unwind the stack. A side effect that is that when a handler is matched
    411 and run it's try block (the guarded statements) and every try statement
     403not unwind the stack. A side effect is that when a handler is matched
     404and run its try block (the guarded statements) and every try statement
    412405searched before it are still on the stack. This can lead to the recursive
    413406resumption problem.
     
    423416}
    424417\end{cfa}
    425 When this code is executed the guarded @throwResume@ will throw, start a
    426 search and match the handler in the @catchResume@ clause. This will be
    427 call and placed on the stack on top of the try-block. The second throw then
    428 throws and will search the same try block and put call another instance of the
     418When this code is executed the guarded @throwResume@ starts a
     419search and matches the handler in the @catchResume@ clause. The handler is
     420called and placed on the stack on top of the try-block. The second throw in the handler
     421searches the same try block and calls another instance of the
    429422same handler leading to an infinite loop.
    430423
    431 This situation is trivial and easy to avoid, but much more complex cycles
     424While this situation is trivial and easy to avoid, much more complex cycles
    432425can form with multiple handlers and different exception types.
    433426
    434 To prevent all of these cases we mask sections of the stack, or equivalently
    435 the try statements on the stack, so that the resumption search skips over
    436 them and continues with the next unmasked section of the stack.
    437 
    438 A section of the stack is marked when it is searched to see if it contains
    439 a handler for an exception and unmarked when that exception has been handled
    440 or the search was completed without finding a handler.
     427To prevent this case, examined try statements on the stack are marked, so that
     428subsequent resumption searches skip over them and continue with the next unmarked section
     429of the stack.
     430Unmarking occurs when that exception is handled
     431or the search completes without finding a handler.
    441432
    442433% This might need a diagram. But it is an important part of the justification
    443434% of the design of the traversal order.
    444 \begin{verbatim}
    445        throwResume2 ----------.
    446             |                 |
    447  generated from handler       |
    448             |                 |
    449          handler              |
    450             |                 |
    451         throwResume1 -----.   :
    452             |             |   :
    453            try            |   : search skip
    454             |             |   :
    455         catchResume  <----'   :
    456             |                 |
    457 \end{verbatim}
    458 
    459 The rules can be remembered as thinking about what would be searched in
    460 termination. So when a throw happens in a handler; a termination handler
     435
     436\begin{center}
     437%\begin{verbatim}
     438%       throwResume2 ----------.
     439%            |                 |
     440% generated from handler       |
     441%            |                 |
     442%         handler              |
     443%            |                 |
     444%        throwResume1 -----.   :
     445%            |             |   :
     446%           try            |   : search skip
     447%            |             |   :
     448%        catchResume  <----'   :
     449%            |                 |
     450%\end{verbatim}
     451\input{stackMarking}
     452\end{center}
     453
     454The resulting search can be understood by thinking about what is searched for
     455termination. When a throw happens in a handler, a termination handler
    461456skips everything from the original throw to the original catch because that
    462 part of the stack has been unwound, a resumption handler skips the same
    463 section of stack because it has been masked.
    464 A throw in a default handler will preform the same search as the original
    465 throw because; for termination nothing has been unwound, for resumption
    466 the mask will be the same.
    467 
    468 The symmetry with termination is why this pattern was picked. Other patterns,
    469 such as marking just the handlers that caught, also work but lack the
    470 symmetry which means there is more to remember.
     457part of the stack is unwound. A resumption handler skips the same
     458section of stack because it is marked.
     459A throw in a resumption default-handler performs the same search as the original
     460@throwResume@ because for resumption nothing has been unwound.
     461
     462The symmetry between resumption masking and termination searching is why this pattern was picked. Other patterns,
     463such as marking just the handlers that caught, also work but the
     464symmetry seems to match programmer intuition.
    471465
    472466\section{Conditional Catch}
    473 Both termination and resumption handler clauses can be given an additional
    474 condition to further control which exceptions they handle:
    475 \begin{cfa}
    476 catch (EXCEPTION_TYPE * NAME ; CONDITION)
     467Both termination and resumption handler-clauses can be given an additional
     468condition to further control which exceptions is handled:
     469\begin{cfa}
     470catch (EXCEPTION_TYPE [* NAME] @; CONDITION@)
    477471\end{cfa}
    478472First, the same semantics is used to match the exception type. Second, if the
    479473exception matches, @CONDITION@ is executed. The condition expression may
    480 reference all names in scope at the beginning of the try block and @NAME@
     474reference all names in the scope of the try block and @NAME@
    481475introduced in the handler clause. If the condition is true, then the handler
    482476matches. Otherwise, the exception search continues as if the exception type
    483477did not match.
     478
     479Conditional catch allows fine-gain matching based on object values as well as exception types.
     480For example, assume the exception hierarchy @OpenFailure@ $\rightarrow$ @CreateFailure@ and these exceptions are raised by function @open@.
     481\begin{cfa}
     482try {
     483        f1 = open( ... ); // open raises CreateFailure/OpenFailure
     484        f2 = open( ... ); //    with the associate file
     485        ...
     486} catch( CreateFailure * f ; @fd( f ) == f1@ ) {
     487        // only handle IO failure for f1
     488} catch( OpenFailure * f ; @fd( f ) == f2@ ) {
     489        // only handle IO failure for f2
     490}
     491\end{cfa}
     492Here, matching is very precise on the I/O exception and particular file with an open problem.
     493This capability cannot be easily mimiced within the handler.
    484494\begin{cfa}
    485495try {
     
    487497        f2 = open( ... );
    488498        ...
    489 } catch( IOFailure * f ; fd( f ) == f1 ) {
    490         // only handle IO failure for f1
    491 }
    492 \end{cfa}
    493 Note, catching @IOFailure@, checking for @f1@ in the handler, and re-raising the
    494 exception if not @f1@ is different because the re-raise does not examine any of
    495 remaining handlers in the current try statement.
    496 
    497 \section{Rethrowing}
    498 \colour{red}{From Andrew: I recomend we talk about why the language doesn't
     499} catch( CreateFailure * f ) {
     500        if ( @fd( f ) == f1@ ) ... else // reraise
     501} catch( OpenFailure * f ) {
     502        if ( @fd( f ) == f2@ ) ... else // reraise
     503}
     504\end{cfa}
     505When an exception @CreateFailure@ is raised, the first handler catches the
     506derived exception and reraises it if the object is inappropriate. The reraise
     507immediately terminates the current guarded block, which precludes the handler
     508for the base exception @OpenFailure@ from consideration for object
     509@f2@. Therefore, the ``catch first, then reraise'' approach is an incomplete
     510substitute for conditional catch.
     511
     512\section{Reraise}
     513\label{s:Rethrowing}
     514\colour{red}{From Andrew: I recommend we talk about why the language doesn't
    499515have rethrows/reraises instead.}
    500516
    501 \label{s:Rethrowing}
    502517Within the handler block or functions called from the handler block, it is
    503518possible to reraise the most recently caught exception with @throw@ or
     
    518533is part of an unwound stack frame. To prevent this problem, a new default
    519534handler is generated that does a program-level abort.
     535\PAB{I don't see how this is different from the normal throw/throwResume.}
    520536
    521537\section{Finally Clauses}
    522 Finally clauses are used to preform unconditional clean-up when leaving a
    523 scope. They are placed at the end of a try statement:
     538Finally clauses are used to perform unconditional clean-up when leaving a
     539scope and appear at the end of a try statement after any catch clauses:
    524540\begin{cfa}
    525541try {
     
    532548The @FINALLY_BLOCK@ is executed when the try statement is removed from the
    533549stack, including when the @GUARDED_BLOCK@ finishes, any termination handler
    534 finishes or during an unwind.
     550finishes, or during an unwind.
    535551The only time the block is not executed is if the program is exited before
    536552the stack is unwound.
    537553
    538554Execution of the finally block should always finish, meaning control runs off
    539 the end of the block. This requirement ensures always continues as if the
    540 finally clause is not present, \ie finally is for cleanup not changing control
     555the end of the block. This requirement ensures execution always continues as if the
     556finally clause is not present, \ie @finally@ is for cleanup not changing control
    541557flow. Because of this requirement, local control flow out of the finally block
    542558is forbidden. The compiler precludes any @break@, @continue@, @fallthru@ or
    543559@return@ that causes control to leave the finally block. Other ways to leave
    544560the finally block, such as a long jump or termination are much harder to check,
    545 and at best requiring additional run-time overhead, and so are mealy
     561and at best require additional run-time overhead, and so are
    546562discouraged.
    547563
    548564Not all languages with exceptions have finally clauses. Notably \Cpp does
    549 without it as descructors serve a similar role. Although destructors and
    550 finally clauses can be used in many of the same areas they have their own
     565without it as destructors serve a similar role. Although destructors and
     566finally clauses can be used in many of the same areas, they have their own
    551567use cases like top-level functions and lambda functions with closures.
    552568Destructors take a bit more work to set up but are much easier to reuse while
    553 finally clauses are good for once offs and can include local information.
     569finally clauses are good for one-off situations and can easily include local information.
    554570
    555571\section{Cancellation}
    556 Cancellation is a stack-level abort, which can be thought of as as an
    557 uncatchable termination. It unwinds the entirety of the current stack, and if
    558 possible forwards the cancellation exception to a different stack.
     572\label{s:Cancellation}
     573Cancellation is a stack-level abort, which can be thought of as an
     574uncatchable termination. It unwinds the entire stack, and when
     575possible, forwards the cancellation exception to a different stack.
    559576
    560577Cancellation is not an exception operation like termination or resumption.
     
    563580throw, this exception is not used in matching only to pass information about
    564581the cause of the cancellation.
    565 (This also means matching cannot fail so there is no default handler either.)
    566 
    567 After @cancel_stack@ is called the exception is copied into the exception
    568 handling mechanism's memory. Then the entirety of the current stack is
     582(This semantics also means matching cannot fail so there is no default handler.)
     583
     584After @cancel_stack@ is called, the exception is copied into the EHM's
     585memory and the current stack is
    569586unwound. After that it depends one which stack is being cancelled.
    570587\begin{description}
    571588\item[Main Stack:]
    572589The main stack is the one used by the program main at the start of execution,
    573 and is the only stack in a sequential program. Even in a concurrent program
    574 the main stack is only dependent on the environment that started the program.
     590and is the only stack in a sequential program. Even in a concurrent program,
     591the main stack is often used as the environment to start the concurrent threads.
    575592Hence, when the main stack is cancelled there is nowhere else in the program
    576 to notify. After the stack is unwound, there is a program-level abort.
     593to go. Hence, after the main stack is unwound, there is a program-level abort.
    577594
    578595\item[Thread Stack:]
    579 A thread stack is created for a @thread@ object or object that satisfies the
     596A thread stack is created for a \CFA @thread@ object or object that satisfies the
    580597@is_thread@ trait. A thread only has two points of communication that must
    581 happen: start and join. As the thread must be running to perform a
    582 cancellation, it must occur after start and before join, so join is used
    583 for communication here.
     598happen: start and join. A thread must be running to perform a
     599cancellation (a thread cannot cancel another thread). Therefore, a cancellation must
     600occur after start and before join, so join is used
     601for cancellation communication.
    584602After the stack is unwound, the thread halts and waits for
    585603another thread to join with it. The joining thread checks for a cancellation,
    586604and if present, resumes exception @ThreadCancelled@.
    587605
     606\begin{sloppypar}
    588607There is a subtle difference between the explicit join (@join@ function) and
    589 implicit join (from a destructor call). The explicit join takes the default
     608implicit join (from a @thread@'s destructor call). The explicit join takes the default
    590609handler (@defaultResumptionHandler@) from its calling context, which is used if
    591610the exception is not caught. The implicit join does a program abort instead.
    592 
     611\end{sloppypar}
     612
     613\PAB{uC++ does not have these issues, but catch(...) is not working.}
     614\begin{lstlisting}[language=uC++]
     615#include <iostream>
     616using namespace std;
     617
     618struct Cl {
     619        ~Cl() { cout << "C" << endl; }
     620};
     621_Coroutine C {
     622        void main() {
     623                Cl c;
     624                try {
     625                        cancel();
     626                } catch( ... ) {
     627                        cout << "..." << endl;
     628                } _Finally {
     629                        cout << "F" << endl;
     630                }
     631                }
     632  public:
     633        void mem() { resume(); }
     634};
     635_Task T {
     636        void main() {
     637                Cl c;
     638                try {
     639                        cancel();
     640                } catch( ... ) {
     641                        cout << "..." << endl;
     642                } _Finally {
     643                        cout << "F" << endl;
     644                }
     645        }
     646};
     647int main() {
     648        C c;
     649        cout << "here1" << endl;
     650        c.mem();
     651        cout << "here2" << endl;
     652        {
     653                T t;
     654        }
     655        cout << "here3" << endl;
     656}
     657\end{lstlisting}
     658
     659\PAB{This discussion should be its own section.}
    593660This semantics is for safety. If an unwind is triggered while another unwind
    594 is underway only one of them can proceed as they both want to ``consume'' the
     661is underway only one of them can proceed as they both want to ``consume" the
    595662stack. Letting both try to proceed leads to very undefined behaviour.
    596663Both termination and cancellation involve unwinding and, since the default
     
    598665happen in an implicate join inside a destructor. So there is an error message
    599666and an abort instead.
     667
    600668\todo{Perhaps have a more general disucssion of unwind collisions before
    601669this point.}
     
    620688for the exception. So it will use the default handler like a regular throw.
    621689\end{description}
     690
     691\PAB{You should have more test programs that compare \CFA EHM to uC++ EHM.}
Note: See TracChangeset for help on using the changeset viewer.