[4706098c] | 1 | \chapter{Exception Features} |
---|
| 2 | |
---|
| 3 | This chapter covers the design and user interface of the \CFA |
---|
[4260566] | 4 | exception-handling mechanism (EHM). % or exception system. |
---|
| 5 | |
---|
[f6106a6] | 6 | We will begin with an overview of EHMs in general. It is not a strict |
---|
| 7 | definition of all EHMs nor an exaustive list of all possible features. |
---|
| 8 | However it does cover the most common structure and features found in them. |
---|
| 9 | |
---|
[4260566] | 10 | % We should cover what is an exception handling mechanism and what is an |
---|
| 11 | % exception before this. Probably in the introduction. Some of this could |
---|
| 12 | % move there. |
---|
| 13 | \paragraph{Raise / Handle} |
---|
| 14 | An exception operation has two main parts: raise and handle. |
---|
| 15 | These terms are sometimes also known as throw and catch but this work uses |
---|
| 16 | throw/catch as a particular kind of raise/handle. |
---|
[f6106a6] | 17 | These are the two parts that the user will write themselves and may |
---|
| 18 | be the only two pieces of the EHM that have any syntax in the language. |
---|
[4260566] | 19 | |
---|
| 20 | \subparagraph{Raise} |
---|
[f6106a6] | 21 | The raise is the starting point for exception handling. It marks the beginning |
---|
| 22 | of exception handling by \newterm{raising} an excepion, which passes it to |
---|
| 23 | the EHM. |
---|
[4260566] | 24 | |
---|
[f6106a6] | 25 | Some well known examples include the @throw@ statements of \Cpp and Java and |
---|
| 26 | the \codePy{raise} statement from Python. In real systems a raise may preform |
---|
| 27 | some other work (such as memory management) but for the purposes of this |
---|
| 28 | overview that can be ignored. |
---|
[4260566] | 29 | |
---|
| 30 | \subparagraph{Handle} |
---|
[f6106a6] | 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. |
---|
| 33 | |
---|
| 34 | A handler has three common features: the previously mentioned user code, a |
---|
| 35 | region of code they cover and an exception label/condition that matches |
---|
| 36 | certain exceptions. |
---|
| 37 | Only raises inside the covered region and raising exceptions that match the |
---|
| 38 | label can be handled by a given handler. |
---|
| 39 | Different EHMs will have different rules to pick a handler |
---|
[de47a9d] | 40 | if multipe handlers could be used such as ``best match" or ``first found". |
---|
[4260566] | 41 | |
---|
[f6106a6] | 42 | The @try@ statements of \Cpp, Java and Python are common examples. All three |
---|
| 43 | also show another common feature of handlers, they are grouped by the covered |
---|
| 44 | region. |
---|
| 45 | |
---|
[4260566] | 46 | \paragraph{Propagation} |
---|
[de47a9d] | 47 | After an exception is raised comes what is usually the biggest step for the |
---|
[f6106a6] | 48 | EHM: finding and setting up the handler. The propogation from raise to |
---|
| 49 | handler can be broken up into three different tasks: searching for a handler, |
---|
| 50 | matching against the handler and installing the handler. |
---|
[de47a9d] | 51 | |
---|
[f6106a6] | 52 | \subparagraph{Searching} |
---|
| 53 | The EHM begins by searching for handlers that might be used to handle |
---|
[de47a9d] | 54 | the exception. Searching is usually independent of the exception that was |
---|
[f6106a6] | 55 | thrown as it looks for handlers that have the raise site in their covered |
---|
| 56 | region. |
---|
| 57 | This includes handlers in the current function, as well as any in callers |
---|
| 58 | on the stack that have the function call in their covered region. |
---|
| 59 | |
---|
| 60 | \subparagraph{Matching} |
---|
| 61 | Each handler found has to be matched with the raised exception. The exception |
---|
| 62 | label defines a condition that be use used with exception and decides if |
---|
| 63 | there is a match or not. |
---|
| 64 | |
---|
| 65 | In languages where the first match is used this step is intertwined with |
---|
| 66 | searching, a match check is preformed immediately after the search finds |
---|
[4260566] | 67 | a possible handler. |
---|
| 68 | |
---|
[f6106a6] | 69 | \subparagraph{Installing} |
---|
| 70 | After a handler is chosen it must be made ready to run. |
---|
| 71 | The implementation can vary widely to fit with the rest of the |
---|
[de47a9d] | 72 | design of the EHM. The installation step might be trivial or it could be |
---|
[4260566] | 73 | the most expensive step in handling an exception. The latter tends to be the |
---|
| 74 | case when stack unwinding is involved. |
---|
[de47a9d] | 75 | |
---|
[f6106a6] | 76 | If a matching handler is not guarantied to be found the EHM will need a |
---|
| 77 | different course of action here in the cases where no handler matches. |
---|
| 78 | This is only required with unchecked exceptions as checked exceptions |
---|
| 79 | (such as in Java) can make than guaranty. |
---|
| 80 | This different action can also be installing a handler but it is usually an |
---|
| 81 | implicat and much more general one. |
---|
[4260566] | 82 | |
---|
| 83 | \subparagraph{Hierarchy} |
---|
[f6106a6] | 84 | A common way to organize exceptions is in a hierarchical structure. |
---|
| 85 | This is especially true in object-orientated languages where the |
---|
[4260566] | 86 | exception hierarchy is a natural extension of the object hierarchy. |
---|
| 87 | |
---|
| 88 | Consider the following hierarchy of exceptions: |
---|
[4706098c] | 89 | \begin{center} |
---|
[de47a9d] | 90 | \setlength{\unitlength}{4000sp}% |
---|
| 91 | \begin{picture}(1605,612)(2011,-1951) |
---|
| 92 | \put(2100,-1411){\vector(1, 0){225}} |
---|
| 93 | \put(3450,-1411){\vector(1, 0){225}} |
---|
| 94 | \put(3550,-1411){\line(0,-1){225}} |
---|
| 95 | \put(3550,-1636){\vector(1, 0){150}} |
---|
| 96 | \put(3550,-1636){\line(0,-1){225}} |
---|
| 97 | \put(3550,-1861){\vector(1, 0){150}} |
---|
| 98 | \put(2025,-1490){\makebox(0,0)[rb]{\LstBasicStyle{exception}}} |
---|
| 99 | \put(2400,-1460){\makebox(0,0)[lb]{\LstBasicStyle{arithmetic}}} |
---|
| 100 | \put(3750,-1460){\makebox(0,0)[lb]{\LstBasicStyle{underflow}}} |
---|
| 101 | \put(3750,-1690){\makebox(0,0)[lb]{\LstBasicStyle{overflow}}} |
---|
| 102 | \put(3750,-1920){\makebox(0,0)[lb]{\LstBasicStyle{zerodivide}}} |
---|
| 103 | \end{picture}% |
---|
[4706098c] | 104 | \end{center} |
---|
[de47a9d] | 105 | |
---|
[4260566] | 106 | A handler labelled with any given exception can handle exceptions of that |
---|
| 107 | type or any child type of that exception. The root of the exception hierarchy |
---|
[f6106a6] | 108 | (here \codeC{exception}) acts as a catch-all, leaf types catch single types |
---|
[4260566] | 109 | and the exceptions in the middle can be used to catch different groups of |
---|
| 110 | related exceptions. |
---|
| 111 | |
---|
| 112 | This system has some notable advantages, such as multiple levels of grouping, |
---|
[de47a9d] | 113 | the ability for libraries to add new exception types and the isolation |
---|
[f6106a6] | 114 | between different sub-hierarchies. |
---|
| 115 | This design is used in \CFA even though it is not a object-orientated |
---|
| 116 | language using different tools to create the hierarchy. |
---|
[4260566] | 117 | |
---|
| 118 | % Could I cite the rational for the Python IO exception rework? |
---|
| 119 | |
---|
| 120 | \paragraph{Completion} |
---|
[de47a9d] | 121 | After the handler has finished the entire exception operation has to complete |
---|
[f6106a6] | 122 | and continue executing somewhere else. This step is usually simple, |
---|
| 123 | both logically and in its implementation, as the installation of the handler |
---|
| 124 | is usually set up to do most of the work. |
---|
[de47a9d] | 125 | |
---|
[f6106a6] | 126 | The EHM can return control to many different places, |
---|
| 127 | the most common are after the handler definition and after the raise. |
---|
[4260566] | 128 | |
---|
| 129 | \paragraph{Communication} |
---|
[f6106a6] | 130 | For effective exception handling, additional information is usually passed |
---|
| 131 | from the raise to the handler. |
---|
| 132 | So far only communication of the exceptions' identity has been covered. |
---|
| 133 | A common method is putting fields into the exception instance and giving the |
---|
| 134 | handler access to them. |
---|
[4260566] | 135 | |
---|
| 136 | \section{Virtuals} |
---|
[f6106a6] | 137 | Virtual types and casts are not part of \CFA's EHM nor are they required for |
---|
| 138 | any EHM. But \CFA uses a hierarchial system of exceptions and this feature |
---|
| 139 | is leveraged to create that. |
---|
| 140 | |
---|
| 141 | % Maybe talk about why the virtual system is so minimal. |
---|
| 142 | % Created for but not a part of the exception system. |
---|
[4260566] | 143 | |
---|
| 144 | The virtual system supports multiple ``trees" of types. Each tree is |
---|
| 145 | a simple hierarchy with a single root type. Each type in a tree has exactly |
---|
[f6106a6] | 146 | one parent -- except for the root type which has zero parents -- and any |
---|
[4260566] | 147 | number of children. |
---|
| 148 | Any type that belongs to any of these trees is called a virtual type. |
---|
| 149 | |
---|
| 150 | % A type's ancestors are its parent and its parent's ancestors. |
---|
| 151 | % The root type has no ancestors. |
---|
[de47a9d] | 152 | % A type's decendents are its children and its children's decendents. |
---|
[4260566] | 153 | |
---|
[de47a9d] | 154 | Every virtual type also has a list of virtual members. Children inherit |
---|
| 155 | their parent's list of virtual members but may add new members to it. |
---|
[f6106a6] | 156 | It is important to note that these are virtual members, not virtual methods |
---|
| 157 | of object-orientated programming, and can be of any type. |
---|
| 158 | However, since \CFA has function pointers and they are allowed, virtual |
---|
| 159 | members can be used to mimic virtual methods. |
---|
[4260566] | 160 | |
---|
[f6106a6] | 161 | Each virtual type has a unique id. |
---|
| 162 | This unique id and all the virtual members are combined |
---|
[de47a9d] | 163 | into a virtual table type. Each virtual type has a pointer to a virtual table |
---|
[4260566] | 164 | as a hidden field. |
---|
| 165 | |
---|
[f6106a6] | 166 | Up until this point the virtual system is similar to ones found in |
---|
| 167 | object-orientated languages but this where \CFA diverges. Objects encapsulate a |
---|
[08e75215] | 168 | single set of behaviours in each type, universally across the entire program, |
---|
[de47a9d] | 169 | and indeed all programs that use that type definition. In this sense the |
---|
[08e75215] | 170 | types are ``closed" and cannot be altered. |
---|
[de47a9d] | 171 | |
---|
[f6106a6] | 172 | In \CFA types do not encapsulate any behaviour. Traits are local and |
---|
[de47a9d] | 173 | types can begin to statify a trait, stop satifying a trait or satify the same |
---|
[f6106a6] | 174 | trait in a different way at any lexical location in the program. |
---|
| 175 | In this sense they are ``open" as they can change at any time. This means it |
---|
| 176 | is implossible to pick a single set of functions that repersent the type's |
---|
| 177 | implementation across the program. |
---|
| 178 | |
---|
| 179 | \CFA side-steps this issue by not having a single virtual table for each |
---|
| 180 | type. A user can define virtual tables which are filled in at their |
---|
| 181 | declaration and given a name. Anywhere that name is visible, even if it was |
---|
| 182 | defined locally inside a function (although that means it will not have a |
---|
| 183 | static lifetime), it can be used. |
---|
| 184 | Specifically, a virtual type is ``bound" to a virtual table which |
---|
[08e75215] | 185 | sets the virtual members for that object. The virtual members can be accessed |
---|
| 186 | through the object. |
---|
[4706098c] | 187 | |
---|
| 188 | While much of the virtual infrastructure is created, it is currently only used |
---|
| 189 | internally for exception handling. The only user-level feature is the virtual |
---|
[29c9b23] | 190 | cast, which is the same as the \Cpp \lstinline[language=C++]|dynamic_cast|. |
---|
[7eb6eb5] | 191 | \label{p:VirtualCast} |
---|
[4706098c] | 192 | \begin{cfa} |
---|
[4a36b344] | 193 | (virtual TYPE)EXPRESSION |
---|
[4706098c] | 194 | \end{cfa} |
---|
[29c9b23] | 195 | Note, the syntax and semantics matches a C-cast, rather than the function-like |
---|
| 196 | \Cpp syntax for special casts. Both the type of @EXPRESSION@ and @TYPE@ must be |
---|
| 197 | a pointer to a virtual type. |
---|
[de47a9d] | 198 | The cast dynamically checks if the @EXPRESSION@ type is the same or a sub-type |
---|
[29c9b23] | 199 | of @TYPE@, and if true, returns a pointer to the |
---|
[4706098c] | 200 | @EXPRESSION@ object, otherwise it returns @0p@ (null pointer). |
---|
| 201 | |
---|
| 202 | \section{Exception} |
---|
[4a36b344] | 203 | % Leaving until later, hopefully it can talk about actual syntax instead |
---|
| 204 | % of my many strange macros. Syntax aside I will also have to talk about the |
---|
| 205 | % features all exceptions support. |
---|
| 206 | |
---|
[4706098c] | 207 | Exceptions are defined by the trait system; there are a series of traits, and |
---|
[1c1c180] | 208 | if a type satisfies them, then it can be used as an exception. The following |
---|
[4706098c] | 209 | is the base trait all exceptions need to match. |
---|
| 210 | \begin{cfa} |
---|
| 211 | trait is_exception(exceptT &, virtualT &) { |
---|
[29c9b23] | 212 | virtualT const & get_exception_vtable(exceptT *); |
---|
[02b73ea] | 213 | }; |
---|
[4706098c] | 214 | \end{cfa} |
---|
[29c9b23] | 215 | The trait is defined over two types, the exception type and the virtual table |
---|
[f6106a6] | 216 | type. This should be one-to-one: each exception type has only one virtual |
---|
[29c9b23] | 217 | table type and vice versa. The only assertion in the trait is |
---|
| 218 | @get_exception_vtable@, which takes a pointer of the exception type and |
---|
[de47a9d] | 219 | returns a reference to the virtual table type instance. |
---|
[29c9b23] | 220 | |
---|
[f6106a6] | 221 | % TODO: This section, and all references to get_exception_vtable, are |
---|
| 222 | % out-of-data. Perhaps wait until the update is finished before rewriting it. |
---|
[29c9b23] | 223 | The function @get_exception_vtable@ is actually a constant function. |
---|
[de47a9d] | 224 | Regardless of the value passed in (including the null pointer) it should |
---|
| 225 | return a reference to the virtual table instance for that type. |
---|
| 226 | The reason it is a function instead of a constant is that it make type |
---|
| 227 | annotations easier to write as you can use the exception type instead of the |
---|
| 228 | virtual table type; which usually has a mangled name. |
---|
[29c9b23] | 229 | % Also \CFA's trait system handles functions better than constants and doing |
---|
[1830a86] | 230 | % it this way reduce the amount of boiler plate we need. |
---|
[29c9b23] | 231 | |
---|
| 232 | % I did have a note about how it is the programmer's responsibility to make |
---|
| 233 | % sure the function is implemented correctly. But this is true of every |
---|
[de47a9d] | 234 | % similar system I know of (except Agda's I guess) so I took it out. |
---|
| 235 | |
---|
[f6106a6] | 236 | There are two more traits for exceptions defined as follows: |
---|
[4706098c] | 237 | \begin{cfa} |
---|
[02b73ea] | 238 | trait is_termination_exception( |
---|
[4706098c] | 239 | exceptT &, virtualT & | is_exception(exceptT, virtualT)) { |
---|
[29c9b23] | 240 | void defaultTerminationHandler(exceptT &); |
---|
[02b73ea] | 241 | }; |
---|
| 242 | |
---|
| 243 | trait is_resumption_exception( |
---|
[4706098c] | 244 | exceptT &, virtualT & | is_exception(exceptT, virtualT)) { |
---|
[29c9b23] | 245 | void defaultResumptionHandler(exceptT &); |
---|
[02b73ea] | 246 | }; |
---|
[4706098c] | 247 | \end{cfa} |
---|
[f6106a6] | 248 | Both traits ensure a pair of types are an exception type and its virtual table |
---|
| 249 | and defines one of the two default handlers. The default handlers are used |
---|
| 250 | as fallbacks and are discussed in detail in \VRef{s:ExceptionHandling}. |
---|
[de47a9d] | 251 | |
---|
[f6106a6] | 252 | However, all three of these traits can be tricky to use directly. |
---|
| 253 | While there is a bit of repetition required, |
---|
[de47a9d] | 254 | the largest issue is that the virtual table type is mangled and not in a user |
---|
[f6106a6] | 255 | facing way. So these three macros are provided to wrap these traits to |
---|
| 256 | simplify referring to the names: |
---|
[29c9b23] | 257 | @IS_EXCEPTION@, @IS_TERMINATION_EXCEPTION@ and @IS_RESUMPTION_EXCEPTION@. |
---|
[1830a86] | 258 | |
---|
[f6106a6] | 259 | All three take one or two arguments. The first argument is the name of the |
---|
| 260 | exception type. The macro passes its unmangled and mangled form to the trait. |
---|
[1830a86] | 261 | The second (optional) argument is a parenthesized list of polymorphic |
---|
[f6106a6] | 262 | arguments. This argument is only used with polymorphic exceptions and the |
---|
| 263 | list is be passed to both types. |
---|
| 264 | In the current set-up, the two types always have the same polymorphic |
---|
| 265 | arguments so these macros can be used without losing flexibility. |
---|
[29c9b23] | 266 | |
---|
| 267 | For example consider a function that is polymorphic over types that have a |
---|
| 268 | defined arithmetic exception: |
---|
| 269 | \begin{cfa} |
---|
[de47a9d] | 270 | forall(Num | IS_EXCEPTION(Arithmetic, (Num))) |
---|
[29c9b23] | 271 | void some_math_function(Num & left, Num & right); |
---|
| 272 | \end{cfa} |
---|
[4706098c] | 273 | |
---|
[1830a86] | 274 | \section{Exception Handling} |
---|
[f6106a6] | 275 | \label{s:ExceptionHandling} |
---|
| 276 | \CFA provides two kinds of exception handling: termination and resumption. |
---|
| 277 | These twin operations are the core of \CFA's exception handling mechanism. |
---|
[de47a9d] | 278 | This section will cover the general patterns shared by the two operations and |
---|
| 279 | then go on to cover the details each individual operation. |
---|
| 280 | |
---|
[f6106a6] | 281 | Both operations follow the same set of steps. |
---|
| 282 | Both start with the user preforming a raise on an exception. |
---|
| 283 | Then the exception propogates up the stack. |
---|
| 284 | If a handler is found the exception is caught and the handler is run. |
---|
| 285 | After that control returns to normal execution. |
---|
[de47a9d] | 286 | If the search fails a default handler is run and then control |
---|
[f6106a6] | 287 | returns to normal execution after the raise. |
---|
| 288 | |
---|
| 289 | This general description covers what the two kinds have in common. |
---|
| 290 | Differences include how propogation is preformed, where exception continues |
---|
| 291 | after an exception is caught and handled and which default handler is run. |
---|
[1830a86] | 292 | |
---|
[4706098c] | 293 | \subsection{Termination} |
---|
| 294 | \label{s:Termination} |
---|
[f6106a6] | 295 | Termination handling is the familiar kind and used in most programming |
---|
[1830a86] | 296 | languages with exception handling. |
---|
[f6106a6] | 297 | It is dynamic, non-local goto. If the raised exception is matched and |
---|
| 298 | handled the stack is unwound and control will (usually) continue the function |
---|
| 299 | on the call stack that defined the handler. |
---|
| 300 | Termination is commonly used when an error has occurred and recovery is |
---|
| 301 | impossible locally. |
---|
[1830a86] | 302 | |
---|
| 303 | % (usually) Control can continue in the current function but then a different |
---|
| 304 | % control flow construct should be used. |
---|
[4706098c] | 305 | |
---|
[f6106a6] | 306 | A termination raise is started with the @throw@ statement: |
---|
[4706098c] | 307 | \begin{cfa} |
---|
[4a36b344] | 308 | throw EXPRESSION; |
---|
[4706098c] | 309 | \end{cfa} |
---|
[29c9b23] | 310 | The expression must return a reference to a termination exception, where the |
---|
[f6106a6] | 311 | termination exception is any type that satisfies the trait |
---|
| 312 | @is_termination_exception@ at the call site. |
---|
| 313 | Through \CFA's trait system the trait functions are implicity passed into the |
---|
| 314 | throw code and the EHM. |
---|
| 315 | A new @defaultTerminationHandler@ can be defined in any scope to |
---|
[de47a9d] | 316 | change the throw's behavior (see below). |
---|
| 317 | |
---|
[f6106a6] | 318 | The throw will copy the provided exception into managed memory to ensure |
---|
| 319 | the exception is not destroyed if the stack is unwound. |
---|
| 320 | It is the user's responsibility to ensure the original exception is cleaned |
---|
| 321 | up wheither the stack is unwound or not. Allocating it on the stack is |
---|
| 322 | usually sufficient. |
---|
[de47a9d] | 323 | |
---|
[f6106a6] | 324 | Then propogation starts with the search. \CFA uses a ``first match" rule so |
---|
| 325 | matching is preformed with the copied exception as the search continues. |
---|
| 326 | It starts from the throwing function and proceeds to the base of the stack, |
---|
[1830a86] | 327 | from callee to caller. |
---|
[de47a9d] | 328 | At each stack frame, a check is made for resumption handlers defined by the |
---|
[1830a86] | 329 | @catch@ clauses of a @try@ statement. |
---|
[4706098c] | 330 | \begin{cfa} |
---|
[4a36b344] | 331 | try { |
---|
[4706098c] | 332 | GUARDED_BLOCK |
---|
[f6106a6] | 333 | } catch (EXCEPTION_TYPE$\(_1\)$ * [NAME$\(_1\)$]) { |
---|
[4706098c] | 334 | HANDLER_BLOCK$\(_1\)$ |
---|
[f6106a6] | 335 | } catch (EXCEPTION_TYPE$\(_2\)$ * [NAME$\(_2\)$]) { |
---|
[4706098c] | 336 | HANDLER_BLOCK$\(_2\)$ |
---|
[4a36b344] | 337 | } |
---|
[4706098c] | 338 | \end{cfa} |
---|
[f6106a6] | 339 | When viewed on its own, a try statement will simply execute the statements |
---|
| 340 | in @GUARDED_BLOCK@ and when those are finished the try statement finishes. |
---|
[de47a9d] | 341 | |
---|
| 342 | However, while the guarded statements are being executed, including any |
---|
[f6106a6] | 343 | invoked functions, all the handlers in the statement are now on the search |
---|
| 344 | path. If a termination exception is thrown and not handled further up the |
---|
| 345 | stack they will be matched against the exception. |
---|
| 346 | |
---|
| 347 | Exception matching checks the handler in each catch clause in the order |
---|
| 348 | they appear, top to bottom. If the representation of the thrown exception type |
---|
| 349 | is the same or a descendant of @EXCEPTION_TYPE@$_i$ then @NAME@$_i$ |
---|
| 350 | (if provided) is |
---|
[29c9b23] | 351 | bound to a pointer to the exception and the statements in @HANDLER_BLOCK@$_i$ |
---|
| 352 | are executed. If control reaches the end of the handler, the exception is |
---|
[de47a9d] | 353 | freed and control continues after the try statement. |
---|
[4706098c] | 354 | |
---|
[f6106a6] | 355 | If no termination handler is found during the search then the default handler |
---|
| 356 | (@defaultTerminationHandler@) is run. |
---|
[de47a9d] | 357 | Through \CFA's trait system the best match at the throw sight will be used. |
---|
| 358 | This function is run and is passed the copied exception. After the default |
---|
| 359 | handler is run control continues after the throw statement. |
---|
[1830a86] | 360 | |
---|
[f6106a6] | 361 | There is a global @defaultTerminationHandler@ that is polymorphic over all |
---|
| 362 | exception types. Since it is so general a more specific handler can be |
---|
| 363 | defined and will be used for those types, effectively overriding the handler |
---|
| 364 | for particular exception type. |
---|
| 365 | The global default termination handler performs a cancellation |
---|
| 366 | \see{\VRef{s:Cancellation}} on the current stack with the copied exception. |
---|
[4706098c] | 367 | |
---|
| 368 | \subsection{Resumption} |
---|
| 369 | \label{s:Resumption} |
---|
| 370 | |
---|
[f6106a6] | 371 | Resumption exception handling is less common than termination but is |
---|
| 372 | just as old~\cite{Goodenough75} and is simpler in many ways. |
---|
| 373 | It is a dynamic, non-local function call. If the raised exception is |
---|
| 374 | matched a closure will be taken from up the stack and executed, |
---|
| 375 | after which the raising function will continue executing. |
---|
[de47a9d] | 376 | These are most often used when an error occurred and if the error is repaired |
---|
| 377 | then the function can continue. |
---|
[8483c39a] | 378 | |
---|
[4706098c] | 379 | A resumption raise is started with the @throwResume@ statement: |
---|
| 380 | \begin{cfa} |
---|
[4a36b344] | 381 | throwResume EXPRESSION; |
---|
[4706098c] | 382 | \end{cfa} |
---|
[f6106a6] | 383 | It works much the same way as the termination throw. |
---|
| 384 | The expression must return a reference to a resumption exception, |
---|
| 385 | where the resumption exception is any type that satisfies the trait |
---|
| 386 | @is_resumption_exception@ at the call site. |
---|
| 387 | The assertions from this trait are available to |
---|
[1830a86] | 388 | the exception system while handling the exception. |
---|
[29c9b23] | 389 | |
---|
[f6106a6] | 390 | At run-time, no exception copy is made. |
---|
| 391 | As the stack is not unwound the exception and |
---|
[de47a9d] | 392 | any values on the stack will remain in scope while the resumption is handled. |
---|
[4706098c] | 393 | |
---|
[f6106a6] | 394 | The EHM then begins propogation. The search starts from the raise in the |
---|
| 395 | resuming function and proceeds to the base of the stack, from callee to caller. |
---|
[1830a86] | 396 | At each stack frame, a check is made for resumption handlers defined by the |
---|
| 397 | @catchResume@ clauses of a @try@ statement. |
---|
[4706098c] | 398 | \begin{cfa} |
---|
[4a36b344] | 399 | try { |
---|
[4706098c] | 400 | GUARDED_BLOCK |
---|
[f6106a6] | 401 | } catchResume (EXCEPTION_TYPE$\(_1\)$ * [NAME$\(_1\)$]) { |
---|
[4706098c] | 402 | HANDLER_BLOCK$\(_1\)$ |
---|
[f6106a6] | 403 | } catchResume (EXCEPTION_TYPE$\(_2\)$ * [NAME$\(_2\)$]) { |
---|
[4706098c] | 404 | HANDLER_BLOCK$\(_2\)$ |
---|
[4a36b344] | 405 | } |
---|
[4706098c] | 406 | \end{cfa} |
---|
[f6106a6] | 407 | % I wonder if there would be some good central place for this. |
---|
| 408 | Note that termination handlers and resumption handlers may be used together |
---|
| 409 | in a single try statement, intermixing @catch@ and @catchResume@ freely. |
---|
| 410 | Each type of handler will only interact with exceptions from the matching |
---|
| 411 | type of raise. |
---|
| 412 | When a try statement is executed it simply executes the statements in the |
---|
| 413 | @GUARDED_BLOCK@ and then finishes. |
---|
| 414 | |
---|
| 415 | However, while the guarded statements are being executed, including any |
---|
| 416 | invoked functions, all the handlers in the statement are now on the search |
---|
| 417 | path. If a resumption exception is reported and not handled further up the |
---|
| 418 | stack they will be matched against the exception. |
---|
| 419 | |
---|
| 420 | Exception matching checks the handler in each catch clause in the order |
---|
| 421 | they appear, top to bottom. If the representation of the thrown exception type |
---|
| 422 | is the same or a descendant of @EXCEPTION_TYPE@$_i$ then @NAME@$_i$ |
---|
| 423 | (if provided) is bound to a pointer to the exception and the statements in |
---|
| 424 | @HANDLER_BLOCK@$_i$ are executed. |
---|
| 425 | If control reaches the end of the handler, execution continues after the |
---|
| 426 | the raise statement that raised the handled exception. |
---|
[de47a9d] | 427 | |
---|
| 428 | Like termination, if no resumption handler is found, the default handler |
---|
| 429 | visible at the throw statement is called. It will use the best match at the |
---|
| 430 | call sight according to \CFA's overloading rules. The default handler is |
---|
| 431 | passed the exception given to the throw. When the default handler finishes |
---|
[f6106a6] | 432 | execution continues after the raise statement. |
---|
[de47a9d] | 433 | |
---|
| 434 | There is a global @defaultResumptionHandler@ is polymorphic over all |
---|
| 435 | termination exceptions and preforms a termination throw on the exception. |
---|
[f6106a6] | 436 | The @defaultTerminationHandler@ for that raise is matched at the original |
---|
| 437 | raise statement (the resumption @throwResume@) and it can be customized by |
---|
[1830a86] | 438 | introducing a new or better match as well. |
---|
| 439 | |
---|
[f6106a6] | 440 | \subsubsection{Resumption Marking} |
---|
[1830a86] | 441 | A key difference between resumption and termination is that resumption does |
---|
[de47a9d] | 442 | not unwind the stack. A side effect that is that when a handler is matched |
---|
| 443 | and run it's try block (the guarded statements) and every try statement |
---|
[1830a86] | 444 | searched before it are still on the stack. This can lead to the recursive |
---|
| 445 | resumption problem. |
---|
| 446 | |
---|
| 447 | The recursive resumption problem is any situation where a resumption handler |
---|
| 448 | ends up being called while it is running. |
---|
| 449 | Consider a trivial case: |
---|
| 450 | \begin{cfa} |
---|
| 451 | try { |
---|
| 452 | throwResume (E &){}; |
---|
| 453 | } catchResume(E *) { |
---|
| 454 | throwResume (E &){}; |
---|
| 455 | } |
---|
| 456 | \end{cfa} |
---|
[de47a9d] | 457 | When this code is executed the guarded @throwResume@ will throw, start a |
---|
| 458 | search and match the handler in the @catchResume@ clause. This will be |
---|
| 459 | call and placed on the stack on top of the try-block. The second throw then |
---|
| 460 | throws and will search the same try block and put call another instance of the |
---|
[1830a86] | 461 | same handler leading to an infinite loop. |
---|
| 462 | |
---|
[de47a9d] | 463 | This situation is trivial and easy to avoid, but much more complex cycles |
---|
[1830a86] | 464 | can form with multiple handlers and different exception types. |
---|
| 465 | |
---|
[f6106a6] | 466 | To prevent all of these cases we mark try statements on the stack. |
---|
| 467 | A try statement is marked when a match check is preformed with it and an |
---|
| 468 | exception. The statement will be unmarked when the handling of that exception |
---|
| 469 | is completed or the search completes without finding a handler. |
---|
| 470 | While a try statement is marked its handlers are never matched, effectify |
---|
| 471 | skipping over it to the next try statement. |
---|
[4a36b344] | 472 | |
---|
[02b73ea] | 473 | % This might need a diagram. But it is an important part of the justification |
---|
[4a36b344] | 474 | % of the design of the traversal order. |
---|
[de47a9d] | 475 | \begin{verbatim} |
---|
| 476 | throwResume2 ----------. |
---|
| 477 | | | |
---|
| 478 | generated from handler | |
---|
| 479 | | | |
---|
| 480 | handler | |
---|
| 481 | | | |
---|
| 482 | throwResume1 -----. : |
---|
| 483 | | | : |
---|
| 484 | try | : search skip |
---|
| 485 | | | : |
---|
| 486 | catchResume <----' : |
---|
| 487 | | | |
---|
| 488 | \end{verbatim} |
---|
| 489 | |
---|
[f6106a6] | 490 | These rules mirror what happens with termination. |
---|
| 491 | When a termination throw happens in a handler the search will not look at |
---|
| 492 | any handlers from the original throw to the original catch because that |
---|
| 493 | part of the stack has been unwound. |
---|
| 494 | A resumption raise in the same situation wants to search the entire stack, |
---|
| 495 | but it will not try to match the exception with try statements in the section |
---|
| 496 | that would have been unwound as they are marked. |
---|
[4706098c] | 497 | |
---|
[f6106a6] | 498 | The symmetry between resumption termination is why this pattern was picked. |
---|
| 499 | Other patterns, such as marking just the handlers that caught, also work but |
---|
| 500 | lack the symmetry means there are less rules to remember. |
---|
[4706098c] | 501 | |
---|
| 502 | \section{Conditional Catch} |
---|
[de47a9d] | 503 | Both termination and resumption handler clauses can be given an additional |
---|
| 504 | condition to further control which exceptions they handle: |
---|
[4706098c] | 505 | \begin{cfa} |
---|
[f6106a6] | 506 | catch (EXCEPTION_TYPE * [NAME] ; CONDITION) |
---|
[4706098c] | 507 | \end{cfa} |
---|
| 508 | First, the same semantics is used to match the exception type. Second, if the |
---|
| 509 | exception matches, @CONDITION@ is executed. The condition expression may |
---|
[de47a9d] | 510 | reference all names in scope at the beginning of the try block and @NAME@ |
---|
[1c1c180] | 511 | introduced in the handler clause. If the condition is true, then the handler |
---|
[1830a86] | 512 | matches. Otherwise, the exception search continues as if the exception type |
---|
| 513 | did not match. |
---|
[f6106a6] | 514 | |
---|
| 515 | The condition matching allows finer matching by allowing the match to check |
---|
| 516 | more kinds of information than just the exception type. |
---|
[4706098c] | 517 | \begin{cfa} |
---|
| 518 | try { |
---|
[f6106a6] | 519 | handle1 = open( f1, ... ); |
---|
| 520 | handle2 = open( f2, ... ); |
---|
| 521 | handle3 = open( f3, ... ); |
---|
[4706098c] | 522 | ... |
---|
[de47a9d] | 523 | } catch( IOFailure * f ; fd( f ) == f1 ) { |
---|
[f6106a6] | 524 | // Only handle IO failure for f1. |
---|
| 525 | } catch( IOFailure * f ; fd( f ) == f3 ) { |
---|
| 526 | // Only handle IO failure for f3. |
---|
[4706098c] | 527 | } |
---|
[f6106a6] | 528 | // Can't handle a failure relating to f2 here. |
---|
[4706098c] | 529 | \end{cfa} |
---|
[f6106a6] | 530 | In this example the file that experianced the IO error is used to decide |
---|
| 531 | which handler should be run, if any at all. |
---|
| 532 | |
---|
| 533 | \begin{comment} |
---|
| 534 | % I know I actually haven't got rid of them yet, but I'm going to try |
---|
| 535 | % to write it as if I had and see if that makes sense: |
---|
| 536 | \section{Reraising} |
---|
| 537 | \label{s:Reraising} |
---|
[4706098c] | 538 | Within the handler block or functions called from the handler block, it is |
---|
| 539 | possible to reraise the most recently caught exception with @throw@ or |
---|
[1830a86] | 540 | @throwResume@, respectively. |
---|
[4706098c] | 541 | \begin{cfa} |
---|
[29c9b23] | 542 | try { |
---|
| 543 | ... |
---|
| 544 | } catch( ... ) { |
---|
[1830a86] | 545 | ... throw; |
---|
[4706098c] | 546 | } catchResume( ... ) { |
---|
[1830a86] | 547 | ... throwResume; |
---|
[4706098c] | 548 | } |
---|
| 549 | \end{cfa} |
---|
| 550 | The only difference between a raise and a reraise is that reraise does not |
---|
| 551 | create a new exception; instead it continues using the current exception, \ie |
---|
| 552 | no allocation and copy. However the default handler is still set to the one |
---|
| 553 | visible at the raise point, and hence, for termination could refer to data that |
---|
| 554 | is part of an unwound stack frame. To prevent this problem, a new default |
---|
| 555 | handler is generated that does a program-level abort. |
---|
[f6106a6] | 556 | \end{comment} |
---|
| 557 | |
---|
| 558 | \subsection{Comparison with Reraising} |
---|
| 559 | A more popular way to allow handlers to match in more detail is to reraise |
---|
| 560 | the exception after it has been caught if it could not be handled here. |
---|
| 561 | On the surface these two features seem interchangable. |
---|
| 562 | |
---|
| 563 | If we used @throw;@ to start a termination reraise then these two statements |
---|
| 564 | would have the same behaviour: |
---|
| 565 | \begin{cfa} |
---|
| 566 | try { |
---|
| 567 | do_work_may_throw(); |
---|
| 568 | } catch(exception_t * exc ; can_handle(exc)) { |
---|
| 569 | handle(exc); |
---|
| 570 | } |
---|
| 571 | \end{cfa} |
---|
| 572 | |
---|
| 573 | \begin{cfa} |
---|
| 574 | try { |
---|
| 575 | do_work_may_throw(); |
---|
| 576 | } catch(exception_t * exc) { |
---|
| 577 | if (can_handle(exc)) { |
---|
| 578 | handle(exc); |
---|
| 579 | } else { |
---|
| 580 | throw; |
---|
| 581 | } |
---|
| 582 | } |
---|
| 583 | \end{cfa} |
---|
| 584 | If there are further handlers after this handler only the first version will |
---|
| 585 | check them. If multiple handlers on a single try block could handle the same |
---|
| 586 | exception the translations get more complex but they are equivilantly |
---|
| 587 | powerful. |
---|
| 588 | |
---|
| 589 | Until stack unwinding comes into the picture. In termination handling, a |
---|
| 590 | conditional catch happens before the stack is unwound, but a reraise happens |
---|
| 591 | afterwards. Normally this might only cause you to loose some debug |
---|
| 592 | information you could get from a stack trace (and that can be side stepped |
---|
| 593 | entirely by collecting information during the unwind). But for \CFA there is |
---|
| 594 | another issue, if the exception isn't handled the default handler should be |
---|
| 595 | run at the site of the original raise. |
---|
| 596 | |
---|
| 597 | There are two problems with this: the site of the original raise doesn't |
---|
| 598 | exist anymore and the default handler might not exist anymore. The site will |
---|
| 599 | always be removed as part of the unwinding, often with the entirety of the |
---|
| 600 | function it was in. The default handler could be a stack allocated nested |
---|
| 601 | function removed during the unwind. |
---|
| 602 | |
---|
| 603 | This means actually trying to pretend the catch didn't happening, continuing |
---|
| 604 | the original raise instead of starting a new one, is infeasible. |
---|
| 605 | That is the expected behaviour for most languages and we can't replicate |
---|
| 606 | that behaviour. |
---|
[4a36b344] | 607 | |
---|
| 608 | \section{Finally Clauses} |
---|
[f6106a6] | 609 | \label{s:FinallyClauses} |
---|
[de47a9d] | 610 | Finally clauses are used to preform unconditional clean-up when leaving a |
---|
[f6106a6] | 611 | scope and are placed at the end of a try statement after any handler clauses: |
---|
[4706098c] | 612 | \begin{cfa} |
---|
[4a36b344] | 613 | try { |
---|
[4706098c] | 614 | GUARDED_BLOCK |
---|
[29c9b23] | 615 | } ... // any number or kind of handler clauses |
---|
| 616 | ... finally { |
---|
[4706098c] | 617 | FINALLY_BLOCK |
---|
[4a36b344] | 618 | } |
---|
[4706098c] | 619 | \end{cfa} |
---|
[29c9b23] | 620 | The @FINALLY_BLOCK@ is executed when the try statement is removed from the |
---|
[1830a86] | 621 | stack, including when the @GUARDED_BLOCK@ finishes, any termination handler |
---|
[de47a9d] | 622 | finishes or during an unwind. |
---|
[29c9b23] | 623 | The only time the block is not executed is if the program is exited before |
---|
[1830a86] | 624 | the stack is unwound. |
---|
[4706098c] | 625 | |
---|
| 626 | Execution of the finally block should always finish, meaning control runs off |
---|
[f6106a6] | 627 | the end of the block. This requirement ensures control always continues as if |
---|
| 628 | the finally clause is not present, \ie finally is for cleanup not changing |
---|
| 629 | control flow. |
---|
| 630 | Because of this requirement, local control flow out of the finally block |
---|
[1c1c180] | 631 | is forbidden. The compiler precludes any @break@, @continue@, @fallthru@ or |
---|
[4706098c] | 632 | @return@ that causes control to leave the finally block. Other ways to leave |
---|
| 633 | the finally block, such as a long jump or termination are much harder to check, |
---|
[f6106a6] | 634 | and at best requiring additional run-time overhead, and so are only |
---|
[1830a86] | 635 | discouraged. |
---|
| 636 | |
---|
[f6106a6] | 637 | Not all languages with unwinding have finally clauses. Notably \Cpp does |
---|
[de47a9d] | 638 | without it as descructors serve a similar role. Although destructors and |
---|
| 639 | finally clauses can be used in many of the same areas they have their own |
---|
[1830a86] | 640 | use cases like top-level functions and lambda functions with closures. |
---|
| 641 | Destructors take a bit more work to set up but are much easier to reuse while |
---|
[f6106a6] | 642 | finally clauses are good for one-off uses and |
---|
| 643 | can easily include local information. |
---|
[4a36b344] | 644 | |
---|
| 645 | \section{Cancellation} |
---|
[f6106a6] | 646 | \label{s:Cancellation} |
---|
[de47a9d] | 647 | Cancellation is a stack-level abort, which can be thought of as as an |
---|
[f6106a6] | 648 | uncatchable termination. It unwinds the entire current stack, and if |
---|
[de47a9d] | 649 | possible forwards the cancellation exception to a different stack. |
---|
[4706098c] | 650 | |
---|
[29c9b23] | 651 | Cancellation is not an exception operation like termination or resumption. |
---|
[4706098c] | 652 | There is no special statement for starting a cancellation; instead the standard |
---|
[1c1c180] | 653 | library function @cancel_stack@ is called passing an exception. Unlike a |
---|
[f6106a6] | 654 | raise, this exception is not used in matching only to pass information about |
---|
[4706098c] | 655 | the cause of the cancellation. |
---|
[f6106a6] | 656 | (This also means matching cannot fail so there is no default handler.) |
---|
[4706098c] | 657 | |
---|
[f6106a6] | 658 | After @cancel_stack@ is called the exception is copied into the EHM's memory |
---|
| 659 | and the current stack is |
---|
[1830a86] | 660 | unwound. After that it depends one which stack is being cancelled. |
---|
[4706098c] | 661 | \begin{description} |
---|
| 662 | \item[Main Stack:] |
---|
| 663 | The main stack is the one used by the program main at the start of execution, |
---|
[f6106a6] | 664 | and is the only stack in a sequential program. |
---|
| 665 | After the main stack is unwound there is a program-level abort. |
---|
| 666 | |
---|
| 667 | There are two reasons for this. The first is that it obviously had to do this |
---|
| 668 | in a sequential program as there is nothing else to notify and the simplicity |
---|
| 669 | of keeping the same behaviour in sequential and concurrent programs is good. |
---|
| 670 | Also, even in concurrent programs there is no stack that an innate connection |
---|
| 671 | to, so it would have be explicitly managed. |
---|
[4706098c] | 672 | |
---|
| 673 | \item[Thread Stack:] |
---|
[f6106a6] | 674 | A thread stack is created for a \CFA @thread@ object or object that satisfies |
---|
| 675 | the @is_thread@ trait. |
---|
| 676 | After a thread stack is unwound there exception is stored until another |
---|
| 677 | thread attempts to join with it. Then the exception @ThreadCancelled@, |
---|
| 678 | which stores a reference to the thread and to the exception passed to the |
---|
| 679 | cancellation, is reported from the join. |
---|
| 680 | There is one difference between an explicit join (with the @join@ function) |
---|
| 681 | and an implicit join (from a destructor call). The explicit join takes the |
---|
| 682 | default handler (@defaultResumptionHandler@) from its calling context while |
---|
| 683 | the implicit join provides its own which does a program abort if the |
---|
| 684 | @ThreadCancelled@ exception cannot be handled. |
---|
| 685 | |
---|
| 686 | Communication is done at join because a thread only has to have to points of |
---|
| 687 | communication with other threads: start and join. |
---|
| 688 | Since a thread must be running to perform a cancellation (and cannot be |
---|
| 689 | cancelled from another stack), the cancellation must be after start and |
---|
| 690 | before the join. So join is the one that we will use. |
---|
| 691 | |
---|
| 692 | % TODO: Find somewhere to discuss unwind collisions. |
---|
| 693 | The difference between the explicit and implicit join is for safety and |
---|
| 694 | debugging. It helps prevent unwinding collisions by avoiding throwing from |
---|
| 695 | a destructor and prevents cascading the error across multiple threads if |
---|
| 696 | the user is not equipped to deal with it. |
---|
| 697 | Also you can always add an explicit join if that is the desired behaviour. |
---|
| 698 | |
---|
| 699 | \item[Coroutine Stack:] |
---|
| 700 | A coroutine stack is created for a @coroutine@ object or object that |
---|
| 701 | satisfies the @is_coroutine@ trait. |
---|
| 702 | After a coroutine stack is unwound control returns to the resume function |
---|
| 703 | that most recently resumed it. The resume statement reports a |
---|
| 704 | @CoroutineCancelled@ exception, which contains a references to the cancelled |
---|
| 705 | coroutine and the exception used to cancel it. |
---|
| 706 | The resume function also takes the @defaultResumptionHandler@ from the |
---|
| 707 | caller's context and passes it to the internal report. |
---|
| 708 | |
---|
| 709 | A coroutine knows of two other coroutines, its starter and its last resumer. |
---|
| 710 | The starter has a much more distant connection while the last resumer just |
---|
| 711 | (in terms of coroutine state) called resume on this coroutine, so the message |
---|
| 712 | is passed to the latter. |
---|
[4706098c] | 713 | \end{description} |
---|