[4706098c] | 1 | \chapter{Exception Features} |
---|
| 2 | |
---|
| 3 | This chapter covers the design and user interface of the \CFA |
---|
| 4 | exception-handling mechanism. |
---|
| 5 | |
---|
| 6 | \section{Virtuals} |
---|
[29c9b23] | 7 | Virtual types and casts are not part of the exception system nor are they |
---|
| 8 | required for an exception system. But an object-oriented style hierarchy is a |
---|
| 9 | great way of organizing exceptions so a minimal virtual system has been added |
---|
| 10 | to \CFA. |
---|
| 11 | |
---|
| 12 | The pattern of a simple hierarchy was borrowed from object-oriented |
---|
| 13 | programming was chosen for several reasons. |
---|
| 14 | The first is that it allows new exceptions to be added in user code |
---|
| 15 | and in libraries independently of each other. Another is it allows for |
---|
| 16 | different levels of exception grouping (all exceptions, all IO exceptions or |
---|
| 17 | a particular IO exception). Also it also provides a simple way of passing |
---|
| 18 | data back and forth across the throw. |
---|
| 19 | |
---|
[4706098c] | 20 | Virtual types and casts are not required for a basic exception-system but are |
---|
| 21 | useful for advanced exception features. However, \CFA is not object-oriented so |
---|
[1c1c180] | 22 | there is no obvious concept of virtuals. Hence, to create advanced exception |
---|
[29c9b23] | 23 | features for this work, I needed to design and implement a virtual-like |
---|
[4706098c] | 24 | system for \CFA. |
---|
| 25 | |
---|
[29c9b23] | 26 | % NOTE: Maybe we should but less of the rational here. |
---|
[4706098c] | 27 | Object-oriented languages often organized exceptions into a simple hierarchy, |
---|
| 28 | \eg Java. |
---|
| 29 | \begin{center} |
---|
| 30 | \setlength{\unitlength}{4000sp}% |
---|
| 31 | \begin{picture}(1605,612)(2011,-1951) |
---|
| 32 | \put(2100,-1411){\vector(1, 0){225}} |
---|
| 33 | \put(3450,-1411){\vector(1, 0){225}} |
---|
| 34 | \put(3550,-1411){\line(0,-1){225}} |
---|
| 35 | \put(3550,-1636){\vector(1, 0){150}} |
---|
| 36 | \put(3550,-1636){\line(0,-1){225}} |
---|
| 37 | \put(3550,-1861){\vector(1, 0){150}} |
---|
| 38 | \put(2025,-1490){\makebox(0,0)[rb]{\LstBasicStyle{exception}}} |
---|
| 39 | \put(2400,-1460){\makebox(0,0)[lb]{\LstBasicStyle{arithmetic}}} |
---|
| 40 | \put(3750,-1460){\makebox(0,0)[lb]{\LstBasicStyle{underflow}}} |
---|
| 41 | \put(3750,-1690){\makebox(0,0)[lb]{\LstBasicStyle{overflow}}} |
---|
| 42 | \put(3750,-1920){\makebox(0,0)[lb]{\LstBasicStyle{zerodivide}}} |
---|
| 43 | \end{picture}% |
---|
| 44 | \end{center} |
---|
| 45 | The hierarchy provides the ability to handle an exception at different degrees |
---|
[1c1c180] | 46 | of specificity (left to right). Hence, it is possible to catch a more general |
---|
[4706098c] | 47 | exception-type in higher-level code where the implementation details are |
---|
| 48 | unknown, which reduces tight coupling to the lower-level implementation. |
---|
| 49 | Otherwise, low-level code changes require higher-level code changes, \eg, |
---|
| 50 | changing from raising @underflow@ to @overflow@ at the low level means changing |
---|
| 51 | the matching catch at the high level versus catching the general @arithmetic@ |
---|
| 52 | exception. In detail, each virtual type may have a parent and can have any |
---|
| 53 | number of children. A type's descendants are its children and its children's |
---|
| 54 | descendants. A type may not be its own descendant. |
---|
| 55 | |
---|
| 56 | The exception hierarchy allows a handler (@catch@ clause) to match multiple |
---|
| 57 | exceptions, \eg a base-type handler catches both base and derived |
---|
| 58 | exception-types. |
---|
| 59 | \begin{cfa} |
---|
| 60 | try { |
---|
| 61 | ... |
---|
| 62 | } catch(arithmetic &) { |
---|
| 63 | ... // handle arithmetic, underflow, overflow, zerodivide |
---|
| 64 | } |
---|
| 65 | \end{cfa} |
---|
| 66 | Most exception mechanisms perform a linear search of the handlers and select |
---|
| 67 | the first matching handler, so the order of handers is now important because |
---|
| 68 | matching is many to one. |
---|
| 69 | |
---|
| 70 | Each virtual type needs an associated virtual table. A virtual table is a |
---|
| 71 | structure with fields for all the virtual members of a type. A virtual type has |
---|
| 72 | all the virtual members of its parent and can add more. It may also update the |
---|
| 73 | values of the virtual members and often does. |
---|
| 74 | |
---|
| 75 | While much of the virtual infrastructure is created, it is currently only used |
---|
| 76 | internally for exception handling. The only user-level feature is the virtual |
---|
[29c9b23] | 77 | cast, which is the same as the \Cpp \lstinline[language=C++]|dynamic_cast|. |
---|
[7eb6eb5] | 78 | \label{p:VirtualCast} |
---|
[4706098c] | 79 | \begin{cfa} |
---|
[4a36b344] | 80 | (virtual TYPE)EXPRESSION |
---|
[4706098c] | 81 | \end{cfa} |
---|
[29c9b23] | 82 | Note, the syntax and semantics matches a C-cast, rather than the function-like |
---|
| 83 | \Cpp syntax for special casts. Both the type of @EXPRESSION@ and @TYPE@ must be |
---|
| 84 | a pointer to a virtual type. |
---|
| 85 | The cast dynamically checks if the @EXPRESSION@ type is the same or a subtype |
---|
| 86 | of @TYPE@, and if true, returns a pointer to the |
---|
[4706098c] | 87 | @EXPRESSION@ object, otherwise it returns @0p@ (null pointer). |
---|
| 88 | |
---|
| 89 | \section{Exception} |
---|
[4a36b344] | 90 | % Leaving until later, hopefully it can talk about actual syntax instead |
---|
| 91 | % of my many strange macros. Syntax aside I will also have to talk about the |
---|
| 92 | % features all exceptions support. |
---|
| 93 | |
---|
[4706098c] | 94 | Exceptions are defined by the trait system; there are a series of traits, and |
---|
[1c1c180] | 95 | if a type satisfies them, then it can be used as an exception. The following |
---|
[4706098c] | 96 | is the base trait all exceptions need to match. |
---|
| 97 | \begin{cfa} |
---|
| 98 | trait is_exception(exceptT &, virtualT &) { |
---|
[29c9b23] | 99 | virtualT const & get_exception_vtable(exceptT *); |
---|
[02b73ea] | 100 | }; |
---|
[4706098c] | 101 | \end{cfa} |
---|
[29c9b23] | 102 | The trait is defined over two types, the exception type and the virtual table |
---|
| 103 | type. This should be one-to-one, each exception type has only one virtual |
---|
| 104 | table type and vice versa. The only assertion in the trait is |
---|
| 105 | @get_exception_vtable@, which takes a pointer of the exception type and |
---|
| 106 | returns a reference to the virtual table type instance. |
---|
| 107 | |
---|
| 108 | The function @get_exception_vtable@ is actually a constant function. |
---|
| 109 | Recardless of the value passed in (including the null pointer) it should |
---|
| 110 | return a reference to the virtual table instance for that type. |
---|
| 111 | The reason it is a function instead of a constant is that it make type |
---|
| 112 | annotations easier to write as you can use the exception type instead of the |
---|
| 113 | virtual table type; which usually has a mangled name. |
---|
| 114 | % Also \CFA's trait system handles functions better than constants and doing |
---|
[1830a86] | 115 | % it this way reduce the amount of boiler plate we need. |
---|
[29c9b23] | 116 | |
---|
| 117 | % I did have a note about how it is the programmer's responsibility to make |
---|
| 118 | % sure the function is implemented correctly. But this is true of every |
---|
| 119 | % similar system I know of (except Agda's I guess) so I took it out. |
---|
[4706098c] | 120 | |
---|
[1830a86] | 121 | There are two more traits for exceptions @is_termination_exception@ and |
---|
| 122 | @is_resumption_exception@. They are defined as follows: |
---|
| 123 | |
---|
[4706098c] | 124 | \begin{cfa} |
---|
[02b73ea] | 125 | trait is_termination_exception( |
---|
[4706098c] | 126 | exceptT &, virtualT & | is_exception(exceptT, virtualT)) { |
---|
[29c9b23] | 127 | void defaultTerminationHandler(exceptT &); |
---|
[02b73ea] | 128 | }; |
---|
| 129 | |
---|
| 130 | trait is_resumption_exception( |
---|
[4706098c] | 131 | exceptT &, virtualT & | is_exception(exceptT, virtualT)) { |
---|
[29c9b23] | 132 | void defaultResumptionHandler(exceptT &); |
---|
[02b73ea] | 133 | }; |
---|
[4706098c] | 134 | \end{cfa} |
---|
| 135 | |
---|
[1830a86] | 136 | In other words they make sure that a given type and virtual type is an |
---|
| 137 | exception and defines one of the two default handlers. These default handlers |
---|
| 138 | are used in the main exception handling operations \see{Exception Handling} |
---|
| 139 | and their use will be detailed there. |
---|
| 140 | |
---|
| 141 | However all three of these traits can be trickly to use directly. |
---|
| 142 | There is a bit of repetition required but |
---|
| 143 | the largest issue is that the virtual table type is mangled and not in a user |
---|
| 144 | facing way. So there are three macros that can be used to wrap these traits |
---|
| 145 | when you need to refer to the names: |
---|
[29c9b23] | 146 | @IS_EXCEPTION@, @IS_TERMINATION_EXCEPTION@ and @IS_RESUMPTION_EXCEPTION@. |
---|
[1830a86] | 147 | |
---|
| 148 | All take one or two arguments. The first argument is the name of the |
---|
| 149 | exception type. Its unmangled and mangled form are passed to the trait. |
---|
| 150 | The second (optional) argument is a parenthesized list of polymorphic |
---|
| 151 | arguments. This argument should only with polymorphic exceptions and the |
---|
| 152 | list will be passed to both types. |
---|
| 153 | In the current set-up the base name and the polymorphic arguments have to |
---|
| 154 | match so these macros can be used without losing flexability. |
---|
[29c9b23] | 155 | |
---|
| 156 | For example consider a function that is polymorphic over types that have a |
---|
| 157 | defined arithmetic exception: |
---|
| 158 | \begin{cfa} |
---|
| 159 | forall(Num | IS_EXCEPTION(Arithmetic, (Num))) |
---|
| 160 | void some_math_function(Num & left, Num & right); |
---|
| 161 | \end{cfa} |
---|
[4706098c] | 162 | |
---|
[1830a86] | 163 | \section{Exception Handling} |
---|
| 164 | \CFA provides two kinds of exception handling, termination and resumption. |
---|
| 165 | These twin operations are the core of the exception handling mechanism and |
---|
| 166 | are the reason for the features of exceptions. |
---|
| 167 | This section will cover the general patterns shared by the two operations and |
---|
| 168 | then go on to cover the details each individual operation. |
---|
| 169 | |
---|
| 170 | Both operations follow the same set of steps to do their operation. They both |
---|
| 171 | start with the user preforming a throw on an exception. |
---|
| 172 | Then there is the search for a handler, if one is found than the exception |
---|
| 173 | is caught and the handler is run. After that control returns to normal |
---|
| 174 | execution. |
---|
| 175 | |
---|
| 176 | If the search fails a default handler is run and then control |
---|
| 177 | returns to normal execution immediately. That is where the default handlers |
---|
| 178 | @defaultTermiationHandler@ and @defaultResumptionHandler@ are used. |
---|
| 179 | |
---|
[4706098c] | 180 | \subsection{Termination} |
---|
| 181 | \label{s:Termination} |
---|
| 182 | |
---|
[1830a86] | 183 | Termination handling is more familiar kind and used in most programming |
---|
| 184 | languages with exception handling. |
---|
| 185 | It is dynamic, non-local goto. If a throw is successful then the stack will |
---|
| 186 | be unwound and control will (usually) continue in a different function on |
---|
| 187 | the call stack. They are commonly used when an error has occured and recovery |
---|
| 188 | is impossible in the current function. |
---|
| 189 | |
---|
| 190 | % (usually) Control can continue in the current function but then a different |
---|
| 191 | % control flow construct should be used. |
---|
[4706098c] | 192 | |
---|
[1830a86] | 193 | A termination throw is started with the @throw@ statement: |
---|
[4706098c] | 194 | \begin{cfa} |
---|
[4a36b344] | 195 | throw EXPRESSION; |
---|
[4706098c] | 196 | \end{cfa} |
---|
[29c9b23] | 197 | The expression must return a reference to a termination exception, where the |
---|
| 198 | termination exception is any type that satifies @is_termination_exception@ |
---|
| 199 | at the call site. |
---|
| 200 | Through \CFA's trait system the functions in the traits are passed into the |
---|
| 201 | throw code. A new @defaultTerminationHandler@ can be defined in any scope to |
---|
| 202 | change the throw's behavior (see below). |
---|
| 203 | |
---|
[1830a86] | 204 | The throw will copy the provided exception into managed memory. It is the |
---|
| 205 | user's responcibility to ensure the original exception is cleaned up if the |
---|
| 206 | stack is unwound (allocating it on the stack should be sufficient). |
---|
[4706098c] | 207 | |
---|
[1830a86] | 208 | Then the exception system searches the stack using the copied exception. |
---|
| 209 | It starts starts from the throw and proceeds to the base of the stack, |
---|
| 210 | from callee to caller. |
---|
| 211 | At each stack frame, a check is made for resumption handlers defined by the |
---|
| 212 | @catch@ clauses of a @try@ statement. |
---|
[4706098c] | 213 | \begin{cfa} |
---|
[4a36b344] | 214 | try { |
---|
[4706098c] | 215 | GUARDED_BLOCK |
---|
[1830a86] | 216 | } catch (EXCEPTION_TYPE$\(_1\)$ * NAME$\(_1\)$) { |
---|
[4706098c] | 217 | HANDLER_BLOCK$\(_1\)$ |
---|
[1830a86] | 218 | } catch (EXCEPTION_TYPE$\(_2\)$ * NAME$\(_2\)$) { |
---|
[4706098c] | 219 | HANDLER_BLOCK$\(_2\)$ |
---|
[4a36b344] | 220 | } |
---|
[4706098c] | 221 | \end{cfa} |
---|
[1830a86] | 222 | When viewed on its own a try statement will simply exceute the statements in |
---|
| 223 | @GUARDED_BLOCK@ and when those are finished the try statement finishes. |
---|
| 224 | |
---|
| 225 | However, while the guarded statements are being executed, including any |
---|
| 226 | functions they invoke, all the handlers following the try block are now |
---|
| 227 | or any functions invoked from those |
---|
| 228 | statements, throws an exception, and the exception |
---|
[4706098c] | 229 | is not handled by a try statement further up the stack, the termination |
---|
| 230 | handlers are searched for a matching exception type from top to bottom. |
---|
| 231 | |
---|
| 232 | Exception matching checks the representation of the thrown exception-type is |
---|
| 233 | the same or a descendant type of the exception types in the handler clauses. If |
---|
[29c9b23] | 234 | it is the same of a descendent of @EXCEPTION_TYPE@$_i$ then @NAME@$_i$ is |
---|
| 235 | bound to a pointer to the exception and the statements in @HANDLER_BLOCK@$_i$ |
---|
| 236 | are executed. If control reaches the end of the handler, the exception is |
---|
| 237 | freed and control continues after the try statement. |
---|
[4706098c] | 238 | |
---|
[1830a86] | 239 | If no handler is found during the search then the default handler is run. |
---|
| 240 | Through \CFA's trait system the best match at the throw sight will be used. |
---|
| 241 | This function is run and is passed the copied exception. After the default |
---|
| 242 | handler is run control continues after the throw statement. |
---|
| 243 | |
---|
| 244 | There is a global @defaultTerminationHandler@ that cancels the current stack |
---|
| 245 | with the copied exception. However it is generic over all exception types so |
---|
| 246 | new default handlers can be defined for different exception types and so |
---|
| 247 | different exception types can have different default handlers. |
---|
[4706098c] | 248 | |
---|
| 249 | \subsection{Resumption} |
---|
| 250 | \label{s:Resumption} |
---|
| 251 | |
---|
[1830a86] | 252 | Resumption exception handling is a less common form than termination but is |
---|
| 253 | just as old~\cite{Goodenough75} and is in some sense simpler. |
---|
| 254 | It is a dynamic, non-local function call. If the throw is successful a |
---|
| 255 | closure will be taken from up the stack and executed, after which the throwing |
---|
| 256 | function will continue executing. |
---|
| 257 | These are most often used when an error occured and if the error is repaired |
---|
| 258 | then the function can continue. |
---|
[4706098c] | 259 | |
---|
| 260 | A resumption raise is started with the @throwResume@ statement: |
---|
| 261 | \begin{cfa} |
---|
[4a36b344] | 262 | throwResume EXPRESSION; |
---|
[4706098c] | 263 | \end{cfa} |
---|
| 264 | The semantics of the @throwResume@ statement are like the @throw@, but the |
---|
[29c9b23] | 265 | expression has return a reference a type that satifies the trait |
---|
[1830a86] | 266 | @is_resumption_exception@. The assertions from this trait are available to |
---|
| 267 | the exception system while handling the exception. |
---|
[29c9b23] | 268 | |
---|
| 269 | At runtime, no copies are made. As the stack is not unwound the exception and |
---|
| 270 | any values on the stack will remain in scope while the resumption is handled. |
---|
[4706098c] | 271 | |
---|
[1830a86] | 272 | Then the exception system searches the stack using the provided exception. |
---|
| 273 | It starts starts from the throw and proceeds to the base of the stack, |
---|
| 274 | from callee to caller. |
---|
| 275 | At each stack frame, a check is made for resumption handlers defined by the |
---|
| 276 | @catchResume@ clauses of a @try@ statement. |
---|
[4706098c] | 277 | \begin{cfa} |
---|
[4a36b344] | 278 | try { |
---|
[4706098c] | 279 | GUARDED_BLOCK |
---|
[29c9b23] | 280 | } catchResume (EXCEPTION_TYPE$\(_1\)$ * NAME$\(_1\)$) { |
---|
[4706098c] | 281 | HANDLER_BLOCK$\(_1\)$ |
---|
[29c9b23] | 282 | } catchResume (EXCEPTION_TYPE$\(_2\)$ * NAME$\(_2\)$) { |
---|
[4706098c] | 283 | HANDLER_BLOCK$\(_2\)$ |
---|
[4a36b344] | 284 | } |
---|
[4706098c] | 285 | \end{cfa} |
---|
[1830a86] | 286 | If the handlers are not involved in a search this will simply execute the |
---|
| 287 | @GUARDED_BLOCK@ and then continue to the next statement. |
---|
| 288 | Its purpose is to add handlers onto the stack. |
---|
| 289 | (Note, termination and resumption handlers may be intermixed in a @try@ |
---|
| 290 | statement but the kind of throw must be the same as the handler for it to be |
---|
| 291 | considered as a possible match.) |
---|
| 292 | |
---|
| 293 | If a search for a resumption handler reaches a try block it will check each |
---|
| 294 | @catchResume@ clause, top-to-bottom. |
---|
| 295 | At each handler if the thrown exception is or is a child type of |
---|
| 296 | @EXCEPTION_TYPE@$_i$ then the a pointer to the exception is bound to |
---|
| 297 | @NAME@$_i$ and then @HANDLER_BLOCK@$_i$ is executed. After the block is |
---|
| 298 | finished control will return to the @throwResume@ statement. |
---|
[4706098c] | 299 | |
---|
| 300 | Like termination, if no resumption handler is found, the default handler |
---|
[1830a86] | 301 | visible at the throw statement is called. It will use the best match at the |
---|
| 302 | call sight according to \CFA's overloading rules. The default handler is |
---|
| 303 | passed the exception given to the throw. When the default handler finishes |
---|
| 304 | execution continues after the throw statement. |
---|
| 305 | |
---|
| 306 | There is a global @defaultResumptionHandler@ is polymorphic over all |
---|
| 307 | termination exceptions and preforms a termination throw on the exception. |
---|
| 308 | The @defaultTerminationHandler@ for that throw is matched at the original |
---|
| 309 | throw statement (the resumption @throwResume@) and it can be customized by |
---|
| 310 | introducing a new or better match as well. |
---|
| 311 | |
---|
| 312 | % \subsubsection? |
---|
| 313 | |
---|
| 314 | A key difference between resumption and termination is that resumption does |
---|
| 315 | not unwind the stack. A side effect that is that when a handler is matched |
---|
| 316 | and run it's try block (the guarded statements) and every try statement |
---|
| 317 | searched before it are still on the stack. This can lead to the recursive |
---|
| 318 | resumption problem. |
---|
| 319 | |
---|
| 320 | The recursive resumption problem is any situation where a resumption handler |
---|
| 321 | ends up being called while it is running. |
---|
| 322 | Consider a trivial case: |
---|
| 323 | \begin{cfa} |
---|
| 324 | try { |
---|
| 325 | throwResume (E &){}; |
---|
| 326 | } catchResume(E *) { |
---|
| 327 | throwResume (E &){}; |
---|
| 328 | } |
---|
| 329 | \end{cfa} |
---|
| 330 | When this code is executed the guarded @throwResume@ will throw, start a |
---|
| 331 | search and match the handler in the @catchResume@ clause. This will be |
---|
| 332 | call and placed on the stack on top of the try-block. The second throw then |
---|
| 333 | throws and will seach the same try block and put call another instance of the |
---|
| 334 | same handler leading to an infinite loop. |
---|
| 335 | |
---|
| 336 | This situation is trivial and easy to avoid, but much more complex cycles |
---|
| 337 | can form with multiple handlers and different exception types. |
---|
| 338 | |
---|
| 339 | To prevent all of these cases we mask sections of the stack, or equvilantly |
---|
| 340 | the try statements on the stack, so that the resumption seach skips over |
---|
| 341 | them and continues with the next unmasked section of the stack. |
---|
| 342 | |
---|
| 343 | A section of the stack is marked when it is searched to see if it contains |
---|
| 344 | a handler for an exception and unmarked when that exception has been handled |
---|
| 345 | or the search was completed without finding a handler. |
---|
[4a36b344] | 346 | |
---|
[02b73ea] | 347 | % This might need a diagram. But it is an important part of the justification |
---|
[4a36b344] | 348 | % of the design of the traversal order. |
---|
[4706098c] | 349 | \begin{verbatim} |
---|
| 350 | throwResume2 ----------. |
---|
| 351 | | | |
---|
| 352 | generated from handler | |
---|
| 353 | | | |
---|
| 354 | handler | |
---|
| 355 | | | |
---|
| 356 | throwResume1 -----. : |
---|
| 357 | | | : |
---|
| 358 | try | : search skip |
---|
| 359 | | | : |
---|
| 360 | catchResume <----' : |
---|
| 361 | | | |
---|
| 362 | \end{verbatim} |
---|
| 363 | |
---|
[1830a86] | 364 | The rules can be remembered as thinking about what would be searched in |
---|
| 365 | termination. So when a throw happens in a handler; a termination handler |
---|
| 366 | skips everything from the original throw to the original catch because that |
---|
| 367 | part of the stack has been unwound, a resumption handler skips the same |
---|
| 368 | section of stack because it has been masked. |
---|
| 369 | A throw in a default handler will preform the same search as the original |
---|
| 370 | throw because; for termination nothing has been unwound, for resumption |
---|
| 371 | the mask will be the same. |
---|
[4706098c] | 372 | |
---|
[1830a86] | 373 | The symmetry with termination is why this pattern was picked. Other patterns, |
---|
| 374 | such as marking just the handlers that caught, also work but lack the |
---|
| 375 | symmetry whih means there is more to remember. |
---|
[4706098c] | 376 | |
---|
| 377 | \section{Conditional Catch} |
---|
[29c9b23] | 378 | Both termination and resumption handler clauses can be given an additional |
---|
| 379 | condition to further control which exceptions they handle: |
---|
[4706098c] | 380 | \begin{cfa} |
---|
[1830a86] | 381 | catch (EXCEPTION_TYPE * NAME ; CONDITION) |
---|
[4706098c] | 382 | \end{cfa} |
---|
| 383 | First, the same semantics is used to match the exception type. Second, if the |
---|
| 384 | exception matches, @CONDITION@ is executed. The condition expression may |
---|
| 385 | reference all names in scope at the beginning of the try block and @NAME@ |
---|
[1c1c180] | 386 | introduced in the handler clause. If the condition is true, then the handler |
---|
[1830a86] | 387 | matches. Otherwise, the exception search continues as if the exception type |
---|
| 388 | did not match. |
---|
[4706098c] | 389 | \begin{cfa} |
---|
| 390 | try { |
---|
| 391 | f1 = open( ... ); |
---|
| 392 | f2 = open( ... ); |
---|
| 393 | ... |
---|
| 394 | } catch( IOFailure * f ; fd( f ) == f1 ) { |
---|
| 395 | // only handle IO failure for f1 |
---|
| 396 | } |
---|
| 397 | \end{cfa} |
---|
| 398 | Note, catching @IOFailure@, checking for @f1@ in the handler, and reraising the |
---|
| 399 | exception if not @f1@ is different because the reraise does not examine any of |
---|
| 400 | remaining handlers in the current try statement. |
---|
| 401 | |
---|
[1830a86] | 402 | \section{Rethrowing} |
---|
| 403 | \colour{red}{From Andrew: I recomend we talk about why the language doesn't |
---|
[29c9b23] | 404 | have rethrows/reraises instead.} |
---|
| 405 | |
---|
[1830a86] | 406 | \label{s:Rethrowing} |
---|
[4706098c] | 407 | Within the handler block or functions called from the handler block, it is |
---|
| 408 | possible to reraise the most recently caught exception with @throw@ or |
---|
[1830a86] | 409 | @throwResume@, respectively. |
---|
[4706098c] | 410 | \begin{cfa} |
---|
[29c9b23] | 411 | try { |
---|
| 412 | ... |
---|
| 413 | } catch( ... ) { |
---|
[1830a86] | 414 | ... throw; |
---|
[4706098c] | 415 | } catchResume( ... ) { |
---|
[1830a86] | 416 | ... throwResume; |
---|
[4706098c] | 417 | } |
---|
| 418 | \end{cfa} |
---|
| 419 | The only difference between a raise and a reraise is that reraise does not |
---|
| 420 | create a new exception; instead it continues using the current exception, \ie |
---|
| 421 | no allocation and copy. However the default handler is still set to the one |
---|
| 422 | visible at the raise point, and hence, for termination could refer to data that |
---|
| 423 | is part of an unwound stack frame. To prevent this problem, a new default |
---|
| 424 | handler is generated that does a program-level abort. |
---|
[4a36b344] | 425 | |
---|
| 426 | \section{Finally Clauses} |
---|
[1830a86] | 427 | Finally clauses are used to preform unconditional clean-up when leaving a |
---|
| 428 | scope. They are placed at the end of a try statement: |
---|
[4706098c] | 429 | \begin{cfa} |
---|
[4a36b344] | 430 | try { |
---|
[4706098c] | 431 | GUARDED_BLOCK |
---|
[29c9b23] | 432 | } ... // any number or kind of handler clauses |
---|
| 433 | ... finally { |
---|
[4706098c] | 434 | FINALLY_BLOCK |
---|
[4a36b344] | 435 | } |
---|
[4706098c] | 436 | \end{cfa} |
---|
[29c9b23] | 437 | The @FINALLY_BLOCK@ is executed when the try statement is removed from the |
---|
[1830a86] | 438 | stack, including when the @GUARDED_BLOCK@ finishes, any termination handler |
---|
| 439 | finishes or during an unwind. |
---|
[29c9b23] | 440 | The only time the block is not executed is if the program is exited before |
---|
[1830a86] | 441 | the stack is unwound. |
---|
[4706098c] | 442 | |
---|
| 443 | Execution of the finally block should always finish, meaning control runs off |
---|
| 444 | the end of the block. This requirement ensures always continues as if the |
---|
| 445 | finally clause is not present, \ie finally is for cleanup not changing control |
---|
[1c1c180] | 446 | flow. Because of this requirement, local control flow out of the finally block |
---|
| 447 | is forbidden. The compiler precludes any @break@, @continue@, @fallthru@ or |
---|
[4706098c] | 448 | @return@ that causes control to leave the finally block. Other ways to leave |
---|
| 449 | the finally block, such as a long jump or termination are much harder to check, |
---|
[1830a86] | 450 | and at best requiring additional run-time overhead, and so are mearly |
---|
| 451 | discouraged. |
---|
| 452 | |
---|
| 453 | Not all languages with exceptions have finally clauses. Notably \Cpp does |
---|
| 454 | without it as descructors serve a similar role. Although destructors and |
---|
| 455 | finally clauses can be used in many of the same areas they have their own |
---|
| 456 | use cases like top-level functions and lambda functions with closures. |
---|
| 457 | Destructors take a bit more work to set up but are much easier to reuse while |
---|
| 458 | finally clauses are good for once offs and can include local information. |
---|
[4a36b344] | 459 | |
---|
| 460 | \section{Cancellation} |
---|
[4706098c] | 461 | Cancellation is a stack-level abort, which can be thought of as as an |
---|
| 462 | uncatchable termination. It unwinds the entirety of the current stack, and if |
---|
| 463 | possible forwards the cancellation exception to a different stack. |
---|
| 464 | |
---|
[29c9b23] | 465 | Cancellation is not an exception operation like termination or resumption. |
---|
[4706098c] | 466 | There is no special statement for starting a cancellation; instead the standard |
---|
[1c1c180] | 467 | library function @cancel_stack@ is called passing an exception. Unlike a |
---|
[1830a86] | 468 | throw, this exception is not used in matching only to pass information about |
---|
[4706098c] | 469 | the cause of the cancellation. |
---|
[1830a86] | 470 | (This also means matching cannot fail so there is no default handler either.) |
---|
[4706098c] | 471 | |
---|
[1830a86] | 472 | After @cancel_stack@ is called the exception is copied into the exception |
---|
| 473 | handling mechanism's memory. Then the entirety of the current stack is |
---|
| 474 | unwound. After that it depends one which stack is being cancelled. |
---|
[4706098c] | 475 | \begin{description} |
---|
| 476 | \item[Main Stack:] |
---|
| 477 | The main stack is the one used by the program main at the start of execution, |
---|
[29c9b23] | 478 | and is the only stack in a sequential program. Even in a concurrent program |
---|
| 479 | the main stack is only dependent on the environment that started the program. |
---|
| 480 | Hence, when the main stack is cancelled there is nowhere else in the program |
---|
| 481 | to notify. After the stack is unwound, there is a program-level abort. |
---|
[4706098c] | 482 | |
---|
| 483 | \item[Thread Stack:] |
---|
| 484 | A thread stack is created for a @thread@ object or object that satisfies the |
---|
[1c1c180] | 485 | @is_thread@ trait. A thread only has two points of communication that must |
---|
[4706098c] | 486 | happen: start and join. As the thread must be running to perform a |
---|
[29c9b23] | 487 | cancellation, it must occur after start and before join, so join is used |
---|
| 488 | for communication here. |
---|
| 489 | After the stack is unwound, the thread halts and waits for |
---|
| 490 | another thread to join with it. The joining thread checks for a cancellation, |
---|
[4706098c] | 491 | and if present, resumes exception @ThreadCancelled@. |
---|
| 492 | |
---|
| 493 | There is a subtle difference between the explicit join (@join@ function) and |
---|
| 494 | implicit join (from a destructor call). The explicit join takes the default |
---|
| 495 | handler (@defaultResumptionHandler@) from its calling context, which is used if |
---|
| 496 | the exception is not caught. The implicit join does a program abort instead. |
---|
| 497 | |
---|
[29c9b23] | 498 | This semantics is for safety. If an unwind is triggered while another unwind |
---|
| 499 | is underway only one of them can proceed as they both want to ``consume'' the |
---|
| 500 | stack. Letting both try to proceed leads to very undefined behaviour. |
---|
| 501 | Both termination and cancellation involve unwinding and, since the default |
---|
| 502 | @defaultResumptionHandler@ preforms a termination that could more easily |
---|
| 503 | happen in an implicate join inside a destructor. So there is an error message |
---|
| 504 | and an abort instead. |
---|
[1830a86] | 505 | \todo{Perhaps have a more general disucssion of unwind collisions before |
---|
| 506 | this point.} |
---|
[29c9b23] | 507 | |
---|
| 508 | The recommended way to avoid the abort is to handle the intial resumption |
---|
| 509 | from the implicate join. If required you may put an explicate join inside a |
---|
| 510 | finally clause to disable the check and use the local |
---|
| 511 | @defaultResumptionHandler@ instead. |
---|
[4706098c] | 512 | |
---|
| 513 | \item[Coroutine Stack:] A coroutine stack is created for a @coroutine@ object |
---|
[1c1c180] | 514 | or object that satisfies the @is_coroutine@ trait. A coroutine only knows of |
---|
[1830a86] | 515 | two other coroutines, its starter and its last resumer. Of the two the last |
---|
| 516 | resumer has the tightest coupling to the coroutine it activated and the most |
---|
| 517 | up-to-date information. |
---|
| 518 | |
---|
| 519 | Hence, cancellation of the active coroutine is forwarded to the last resumer |
---|
| 520 | after the stack is unwound. When the resumer restarts, it resumes exception |
---|
[4706098c] | 521 | @CoroutineCancelled@, which is polymorphic over the coroutine type and has a |
---|
| 522 | pointer to the cancelled coroutine. |
---|
| 523 | |
---|
| 524 | The resume function also has an assertion that the @defaultResumptionHandler@ |
---|
| 525 | for the exception. So it will use the default handler like a regular throw. |
---|
| 526 | \end{description} |
---|