[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. |
---|
[8483c39a] | 5 | While an EHM is free to add many features, |
---|
| 6 | the following overview covers the basic features that all EHMs use, but it is not an |
---|
| 7 | exhaustive list of everything an EHM can do. |
---|
[4260566] | 8 | |
---|
| 9 | % We should cover what is an exception handling mechanism and what is an |
---|
| 10 | % exception before this. Probably in the introduction. Some of this could |
---|
| 11 | % move there. |
---|
| 12 | \paragraph{Raise / Handle} |
---|
| 13 | An exception operation has two main parts: raise and handle. |
---|
| 14 | These terms are sometimes also known as throw and catch but this work uses |
---|
| 15 | throw/catch as a particular kind of raise/handle. |
---|
[8483c39a] | 16 | These are the two parts a programmer writes and so |
---|
| 17 | are the only two pieces of the EHM that have language syntax. |
---|
[4260566] | 18 | |
---|
| 19 | \subparagraph{Raise} |
---|
[8483c39a] | 20 | The raise is the starting point for exception handling and usually how \PAB{This sentence is cut off.} |
---|
| 21 | Some well known examples include the @throw@ statement of \Cpp and Java and |
---|
| 22 | the \lstinline[language=Python]{raise} statement from Python. |
---|
[4260566] | 23 | |
---|
[8483c39a] | 24 | For this overview, a raise starts the handling of an |
---|
| 25 | exception, which is called \newterm{raising} an exception. This simple description is sufficient |
---|
| 26 | for the overview. |
---|
[4260566] | 27 | |
---|
| 28 | \subparagraph{Handle} |
---|
[8483c39a] | 29 | The purpose of raising an exception is to run user code to address (handle) the |
---|
| 30 | issue found at the raise point. |
---|
| 31 | The @try@ statement of \Cpp illustrates a common approach for specifying multiple handlers. |
---|
| 32 | A handler has three common features: the scope in which it applies, an |
---|
| 33 | exception label that describes what exceptions it can handle, and code to run |
---|
| 34 | that deals with the raised issue. |
---|
| 35 | Each handler can handle exceptions raised in the region matching its |
---|
| 36 | exception label. For multiple matches, different EHMs have different rules for matching an exception to a handler label, |
---|
| 37 | such as ``best match" or ``first found". |
---|
[4260566] | 38 | |
---|
| 39 | \paragraph{Propagation} |
---|
[8483c39a] | 40 | After an exception is raised, comes the most complex step for the |
---|
| 41 | EHM: finding and setting up the handler. This propagation of exception from raise to handler can be broken up into three |
---|
| 42 | different tasks: searching, matching, and |
---|
| 43 | installing the handler so it can execute. |
---|
| 44 | |
---|
| 45 | \subparagraph{Searching} |
---|
| 46 | The EHM searches for possible handlers that can be used to handle |
---|
| 47 | the exception. Searching is usually independent of the exception that is |
---|
| 48 | thrown and instead depends on the call stack: current function, its caller |
---|
[4260566] | 49 | and repeating down the stack. |
---|
| 50 | |
---|
[8483c39a] | 51 | \subparagraph{Matching} |
---|
| 52 | For each handler found, it compares the raised exception with the handler label to see which one is the |
---|
| 53 | best match, and hence, which one should be used to handle the exception. |
---|
| 54 | In languages where the best match is the first match, these two steps are often |
---|
| 55 | intertwined, \ie a match check is performed immediately after the search finds |
---|
[4260566] | 56 | a possible handler. |
---|
| 57 | |
---|
[8483c39a] | 58 | \subparagraph{Installing} |
---|
| 59 | After a handler is chosen, it must be made ready to run. |
---|
| 60 | This step varies widely to fit with the rest of the |
---|
| 61 | design of the EHM. The installation step might be trivial or it can be |
---|
[4260566] | 62 | the most expensive step in handling an exception. The latter tends to be the |
---|
| 63 | case when stack unwinding is involved. |
---|
[8483c39a] | 64 | An alternate action occurs if no appropriate handler is found, then some implicit action |
---|
| 65 | is performed. This step is only required with unchecked |
---|
| 66 | exceptions as checked exceptions (Java) promise a handler is always found. The implicit action |
---|
| 67 | also installs a handler but it is a default handle that may be |
---|
[4260566] | 68 | installed differently. |
---|
| 69 | |
---|
| 70 | \subparagraph{Hierarchy} |
---|
[8483c39a] | 71 | Some EHM (\CFA, Java) organize exceptions in a hierarchical structure. |
---|
| 72 | This strategy is borrowed from object-orientated languages where the |
---|
[4260566] | 73 | exception hierarchy is a natural extension of the object hierarchy. |
---|
| 74 | |
---|
| 75 | Consider the following hierarchy of exceptions: |
---|
[4706098c] | 76 | \begin{center} |
---|
[8483c39a] | 77 | \input{exceptionHierarchy} |
---|
[4706098c] | 78 | \end{center} |
---|
[4260566] | 79 | A handler labelled with any given exception can handle exceptions of that |
---|
| 80 | type or any child type of that exception. The root of the exception hierarchy |
---|
[8483c39a] | 81 | (here \lstinline[language=C++]{exception}) acts as a catch-all, leaf types catch single types |
---|
[4260566] | 82 | and the exceptions in the middle can be used to catch different groups of |
---|
| 83 | related exceptions. |
---|
| 84 | |
---|
| 85 | This system has some notable advantages, such as multiple levels of grouping, |
---|
[8483c39a] | 86 | the ability for libraries to add new exception types, and the isolation |
---|
| 87 | between different sub-hierarchies. This capability had to be adapted for \CFA, which is a |
---|
[4260566] | 88 | non-object-orientated language. |
---|
| 89 | |
---|
| 90 | % Could I cite the rational for the Python IO exception rework? |
---|
| 91 | |
---|
| 92 | \paragraph{Completion} |
---|
[8483c39a] | 93 | After the handler has returned, the entire exception operation has to complete |
---|
| 94 | and continue executing somewhere. This step is usually simple, |
---|
| 95 | both logically and in its implementation, as the installation of the handler |
---|
| 96 | usually does the preparation. |
---|
| 97 | The EHM can return control to different places, |
---|
| 98 | where the most common are after the handler definition or after the raise. |
---|
[4260566] | 99 | |
---|
| 100 | \paragraph{Communication} |
---|
[8483c39a] | 101 | For effective exception handling, additional information is usually passed from the raise, |
---|
| 102 | where this basic model only communicates the exception's identity. A common |
---|
| 103 | methods for communication is putting fields into an exception and |
---|
| 104 | allowing a handler to access these fields via an exception instance in the handler's scope. |
---|
[4260566] | 105 | |
---|
| 106 | \section{Virtuals} |
---|
[8483c39a] | 107 | Virtual types and casts are not part of an EHM nor are they |
---|
| 108 | required for an EHM. But as pointed out, an object-oriented-style hierarchy is an |
---|
| 109 | excellent way of organizing exceptions. Hence, a minimal virtual system has been added |
---|
| 110 | to \CFA to support hierarchical exceptions. |
---|
[4260566] | 111 | |
---|
| 112 | The virtual system supports multiple ``trees" of types. Each tree is |
---|
| 113 | a simple hierarchy with a single root type. Each type in a tree has exactly |
---|
[8483c39a] | 114 | one parent -- except for the root type with zero parents -- and any |
---|
[4260566] | 115 | number of children. |
---|
| 116 | Any type that belongs to any of these trees is called a virtual type. |
---|
| 117 | |
---|
| 118 | % A type's ancestors are its parent and its parent's ancestors. |
---|
| 119 | % The root type has no ancestors. |
---|
[8483c39a] | 120 | % A type's descendents are its children and its children's descendents. |
---|
[4260566] | 121 | |
---|
[8483c39a] | 122 | Every virtual type has a list of virtual members. Children inherit |
---|
| 123 | their parent's virtual members but may add new members to it. |
---|
| 124 | It is important to note that these are virtual members, not virtual methods of an object type. |
---|
| 125 | However, as \CFA has function pointers, they can be used to mimic virtual |
---|
| 126 | methods. |
---|
[4260566] | 127 | |
---|
[8483c39a] | 128 | Each virtual type has a unique id. |
---|
| 129 | The unique id for the virtual type and all its virtual members are combined |
---|
| 130 | into a virtual-table type. Each virtual type has a pointer to a virtual table |
---|
[4260566] | 131 | as a hidden field. |
---|
| 132 | |
---|
[8483c39a] | 133 | Up to this point, a virtual system is similar to ones found in object-oriented |
---|
| 134 | languages but this is where \CFA diverges. Objects encapsulate a |
---|
[08e75215] | 135 | single set of behaviours in each type, universally across the entire program, |
---|
[8483c39a] | 136 | and indeed all programs that use that type definition. In this sense, the |
---|
[08e75215] | 137 | types are ``closed" and cannot be altered. |
---|
[8483c39a] | 138 | However, \CFA types do not encapsulate any behaviour. Instead, traits are used and |
---|
| 139 | types can satisfy a trait, stop satisfying a trait, or satisfy the same |
---|
| 140 | trait 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 |
---|
| 142 | a single set of functions that represent the type's virtual members. |
---|
| 143 | |
---|
| 144 | Hence, \CFA does not have a single virtual table for a type. A user can define different virtual tables, |
---|
| 145 | which are filled in at their declaration and given a name. |
---|
| 146 | That name is used as the virtual table, even if it is defined locally |
---|
| 147 | inside a function, although lifetime issues must be considered. |
---|
| 148 | Specifically, an object of a virtual type is ``bound" to a virtual table instance, which |
---|
[08e75215] | 149 | sets the virtual members for that object. The virtual members can be accessed |
---|
| 150 | through the object. |
---|
[4706098c] | 151 | |
---|
| 152 | While much of the virtual infrastructure is created, it is currently only used |
---|
| 153 | internally for exception handling. The only user-level feature is the virtual |
---|
[29c9b23] | 154 | cast, which is the same as the \Cpp \lstinline[language=C++]|dynamic_cast|. |
---|
[7eb6eb5] | 155 | \label{p:VirtualCast} |
---|
[4706098c] | 156 | \begin{cfa} |
---|
[4a36b344] | 157 | (virtual TYPE)EXPRESSION |
---|
[4706098c] | 158 | \end{cfa} |
---|
[29c9b23] | 159 | Note, the syntax and semantics matches a C-cast, rather than the function-like |
---|
| 160 | \Cpp syntax for special casts. Both the type of @EXPRESSION@ and @TYPE@ must be |
---|
| 161 | a pointer to a virtual type. |
---|
[8483c39a] | 162 | The cast dynamically checks if the @EXPRESSION@ type is the same or a subtype |
---|
[29c9b23] | 163 | of @TYPE@, and if true, returns a pointer to the |
---|
[4706098c] | 164 | @EXPRESSION@ object, otherwise it returns @0p@ (null pointer). |
---|
| 165 | |
---|
| 166 | \section{Exception} |
---|
[4a36b344] | 167 | % Leaving until later, hopefully it can talk about actual syntax instead |
---|
| 168 | % of my many strange macros. Syntax aside I will also have to talk about the |
---|
| 169 | % features all exceptions support. |
---|
| 170 | |
---|
[4706098c] | 171 | Exceptions are defined by the trait system; there are a series of traits, and |
---|
[1c1c180] | 172 | if a type satisfies them, then it can be used as an exception. The following |
---|
[4706098c] | 173 | is the base trait all exceptions need to match. |
---|
| 174 | \begin{cfa} |
---|
| 175 | trait is_exception(exceptT &, virtualT &) { |
---|
[29c9b23] | 176 | virtualT const & get_exception_vtable(exceptT *); |
---|
[02b73ea] | 177 | }; |
---|
[4706098c] | 178 | \end{cfa} |
---|
[29c9b23] | 179 | The trait is defined over two types, the exception type and the virtual table |
---|
[8483c39a] | 180 | type. These type should have a one-to-one relationship: each exception type has only one virtual |
---|
[29c9b23] | 181 | table type and vice versa. The only assertion in the trait is |
---|
| 182 | @get_exception_vtable@, which takes a pointer of the exception type and |
---|
[8483c39a] | 183 | returns a reference to the virtual-table type-instance. |
---|
[29c9b23] | 184 | |
---|
| 185 | The function @get_exception_vtable@ is actually a constant function. |
---|
[8483c39a] | 186 | Regardless of the value passed in (including the null pointer) it |
---|
| 187 | returns a reference to the virtual-table instance for that type. |
---|
| 188 | The reason it is a function instead of a constant is to make type |
---|
| 189 | annotations easier to write using the exception type rather than the |
---|
| 190 | virtual-table type, which usually has a mangled name because it is an internal component of the EHM. |
---|
[29c9b23] | 191 | % Also \CFA's trait system handles functions better than constants and doing |
---|
[1830a86] | 192 | % it this way reduce the amount of boiler plate we need. |
---|
[29c9b23] | 193 | |
---|
| 194 | % I did have a note about how it is the programmer's responsibility to make |
---|
| 195 | % sure the function is implemented correctly. But this is true of every |
---|
[8483c39a] | 196 | % similar system I know of (except Ada's I guess) so I took it out. |
---|
[1830a86] | 197 | |
---|
[8483c39a] | 198 | There are two more exception traits defined as follows: |
---|
[4706098c] | 199 | \begin{cfa} |
---|
[02b73ea] | 200 | trait is_termination_exception( |
---|
[4706098c] | 201 | exceptT &, virtualT & | is_exception(exceptT, virtualT)) { |
---|
[29c9b23] | 202 | void defaultTerminationHandler(exceptT &); |
---|
[02b73ea] | 203 | }; |
---|
| 204 | |
---|
| 205 | trait is_resumption_exception( |
---|
[4706098c] | 206 | exceptT &, virtualT & | is_exception(exceptT, virtualT)) { |
---|
[29c9b23] | 207 | void defaultResumptionHandler(exceptT &); |
---|
[02b73ea] | 208 | }; |
---|
[4706098c] | 209 | \end{cfa} |
---|
[8483c39a] | 210 | These traits ensure a given type and virtual type are an |
---|
| 211 | exception type and defines one of the two default handlers. The default handlers |
---|
| 212 | are used in the main exception-handling operations and discussed in detail in \VRef{s:ExceptionHandling}. |
---|
| 213 | |
---|
| 214 | However, all three of these traits are tricky to use directly. |
---|
| 215 | While there is a bit of repetition required, |
---|
| 216 | the largest issue is that the virtual-table type is mangled and not in a user |
---|
| 217 | facing way. So three macros are provided to wrap these traits |
---|
| 218 | to simplify referring to the names: |
---|
[29c9b23] | 219 | @IS_EXCEPTION@, @IS_TERMINATION_EXCEPTION@ and @IS_RESUMPTION_EXCEPTION@. |
---|
[1830a86] | 220 | |
---|
[8483c39a] | 221 | These macros take one or two arguments. The first argument is the name of the |
---|
| 222 | exception type. The macro passes the unmangled and mangled form to the trait. |
---|
[1830a86] | 223 | The second (optional) argument is a parenthesized list of polymorphic |
---|
[8483c39a] | 224 | arguments. This argument is only used with polymorphic exceptions and the |
---|
| 225 | list is passed to both types. |
---|
| 226 | In the current set-up, the base name and the polymorphic arguments have to |
---|
[4260566] | 227 | match so these macros can be used without losing flexibility. |
---|
[29c9b23] | 228 | |
---|
| 229 | For example consider a function that is polymorphic over types that have a |
---|
| 230 | defined arithmetic exception: |
---|
| 231 | \begin{cfa} |
---|
[8483c39a] | 232 | forall(Num | @IS_EXCEPTION(Arithmetic, Num)@) |
---|
[29c9b23] | 233 | void some_math_function(Num & left, Num & right); |
---|
| 234 | \end{cfa} |
---|
[8483c39a] | 235 | where the function may raise exception @Arithmetic@ or any of its decedents. |
---|
[4706098c] | 236 | |
---|
[1830a86] | 237 | \section{Exception Handling} |
---|
[8483c39a] | 238 | \label{s:ExceptionHandling} |
---|
| 239 | \CFA provides two kinds of exception handling: termination and resumption. |
---|
| 240 | These twin mechanisms are the core of the \CFA EHM and |
---|
| 241 | multiple features are provided to support them. |
---|
| 242 | This section covers the general patterns shared by the two kinds of exceptions and |
---|
| 243 | then covers the individual detail operations. |
---|
| 244 | |
---|
| 245 | Both mechanisms follow the same set of steps to do their operations. Both |
---|
| 246 | start with the user performing an exception raise. |
---|
| 247 | Then there is the handler search. If one is found, than the exception |
---|
| 248 | is caught and the handler is run. When the handler returns, control returns to an |
---|
| 249 | location appropriate for each kind of exception. |
---|
| 250 | |
---|
| 251 | \begin{sloppypar} |
---|
| 252 | If the search fails, an appropriate default handler, @defaultTermiationHandler@ |
---|
| 253 | or @defaultResumptionHandler@, is run and control returns to the |
---|
| 254 | appropriate location. |
---|
| 255 | \end{sloppypar} |
---|
[1830a86] | 256 | |
---|
[4706098c] | 257 | \subsection{Termination} |
---|
| 258 | \label{s:Termination} |
---|
[8483c39a] | 259 | Termination handling is familiar and used in most programming |
---|
[1830a86] | 260 | languages with exception handling. |
---|
[8483c39a] | 261 | It is a dynamic, non-local goto. The raise starts searching, and if matched and handled, the stack is |
---|
| 262 | unwound and control (usually) continues in the function on |
---|
| 263 | the call stack containing the handler. Terminate is commonly used for an error where recovery |
---|
| 264 | is impossible in the function performing the raise. |
---|
[1830a86] | 265 | |
---|
| 266 | % (usually) Control can continue in the current function but then a different |
---|
| 267 | % control flow construct should be used. |
---|
[4706098c] | 268 | |
---|
[8483c39a] | 269 | A termination raise is started with the @throw@ statement: |
---|
[4706098c] | 270 | \begin{cfa} |
---|
[4a36b344] | 271 | throw EXPRESSION; |
---|
[4706098c] | 272 | \end{cfa} |
---|
[29c9b23] | 273 | The expression must return a reference to a termination exception, where the |
---|
[8483c39a] | 274 | termination exception is any type that satisfies trait |
---|
| 275 | @is_termination_exception@ at the call site. Through \CFA's trait system, the |
---|
| 276 | trait functions are implicitly passed into the hidden throw code and available |
---|
| 277 | to the exception system while handling the exception. A new |
---|
| 278 | @defaultTerminationHandler@ can be defined in any scope to change the throw's |
---|
| 279 | unhandled behaviour (see below). |
---|
| 280 | |
---|
| 281 | The throw must copy the provided exception into managed memory because the stack is unwounded. |
---|
| 282 | The lifetime of the exception copy is managed by the exception runtime. |
---|
| 283 | It is the user's responsibility to ensure the original exception is cleaned up, where allocating it on the unwound stack is sufficient. |
---|
| 284 | |
---|
| 285 | The exception search walks the stack matching with the copied exception. |
---|
| 286 | It starts from the throwing function and proceeds to the base of the stack, |
---|
[1830a86] | 287 | from callee to caller. |
---|
[8483c39a] | 288 | At each stack frame, a check is made for termination handlers defined by the |
---|
[1830a86] | 289 | @catch@ clauses of a @try@ statement. |
---|
[4706098c] | 290 | \begin{cfa} |
---|
[4a36b344] | 291 | try { |
---|
[4706098c] | 292 | GUARDED_BLOCK |
---|
[8483c39a] | 293 | } catch (EXCEPTION_TYPE$\(_1\)$ [* NAME$\(_1\)$]) { |
---|
[4706098c] | 294 | HANDLER_BLOCK$\(_1\)$ |
---|
[8483c39a] | 295 | } catch (EXCEPTION_TYPE$\(_2\)$ [* NAME$\(_2\)$]) { |
---|
[4706098c] | 296 | HANDLER_BLOCK$\(_2\)$ |
---|
[4a36b344] | 297 | } |
---|
[4706098c] | 298 | \end{cfa} |
---|
[8483c39a] | 299 | When viewed on its own, a @try@ statement with @catch@ clauses simply executes the statements in |
---|
| 300 | the @GUARDED_BLOCK@, and when those are finished, the try statement finishes. |
---|
| 301 | |
---|
| 302 | However, while the guarded statements are being executed, including any invoked |
---|
| 303 | functions, a termination exception may be thrown. If that exception is not handled by a try |
---|
| 304 | statement further up the stack, the handlers following the try block are now |
---|
| 305 | searched for a matching termination exception-type from top to bottom. |
---|
| 306 | |
---|
| 307 | Exception matching checks each @catch@ clasue from top to bottom, if the representation of the thrown exception-type is |
---|
| 308 | the same or a descendant type of the exception types in the @catch@ clauses. If |
---|
| 309 | it is the same or a descendant of @EXCEPTION_TYPE@$_i$, then the optional @NAME@$_i$ is |
---|
[29c9b23] | 310 | bound to a pointer to the exception and the statements in @HANDLER_BLOCK@$_i$ |
---|
| 311 | are executed. If control reaches the end of the handler, the exception is |
---|
[8483c39a] | 312 | freed and control continues after the @try@ statement. |
---|
[4706098c] | 313 | |
---|
[8483c39a] | 314 | If no termination handler is found during the search, the default termination |
---|
| 315 | handler visible at the raise is called. Through \CFA's trait-system the best |
---|
| 316 | default-handler match at the throw sight is used. This function is |
---|
| 317 | passed the copied exception given to the raise. After the default handler is |
---|
| 318 | run, control continues after the @throw@ statement. |
---|
[1830a86] | 319 | |
---|
[8483c39a] | 320 | There is a global @defaultTerminationHandler@ function that that is polymorphic |
---|
| 321 | over all exception types allowing new default handlers to be defined for |
---|
| 322 | different exception types and so different exception types can have different |
---|
| 323 | default handlers. The global default termination-handler performs a |
---|
| 324 | cancellation \see{\VRef{s:Cancellation}} on the current stack with the copied |
---|
| 325 | exception. |
---|
[4706098c] | 326 | |
---|
| 327 | \subsection{Resumption} |
---|
| 328 | \label{s:Resumption} |
---|
[8483c39a] | 329 | Resumption exception-handling is a less common counterpart to termination but is |
---|
| 330 | just as old~\cite{Goodenough75} and is simpler to understand. |
---|
| 331 | It is a dynamic, non-local function call (like Lisp). If the throw is successful, a |
---|
| 332 | closure is taken from up the stack and executed, after which the throwing |
---|
| 333 | function continues executing. |
---|
| 334 | Resumption is used when an error occurred, and if the error is repaired, |
---|
[1830a86] | 335 | then the function can continue. |
---|
[4706098c] | 336 | |
---|
[8483c39a] | 337 | An alternative approach is explicitly passing fixup functions with local |
---|
| 338 | closures up the stack to be called when an error occurs. However, fixup |
---|
| 339 | functions significantly expand the parameters list of functions, even when the |
---|
| 340 | fixup function is not used by a function but must be passed to other called |
---|
| 341 | functions. |
---|
| 342 | |
---|
[4706098c] | 343 | A resumption raise is started with the @throwResume@ statement: |
---|
| 344 | \begin{cfa} |
---|
[4a36b344] | 345 | throwResume EXPRESSION; |
---|
[4706098c] | 346 | \end{cfa} |
---|
[8483c39a] | 347 | Like termination, the expression must return a reference to a resumption |
---|
| 348 | exception, where the resumption exception is any type that satisfies the trait |
---|
| 349 | @is_termination_exception@ at the call site. |
---|
| 350 | The assertions for this trait are available to |
---|
[1830a86] | 351 | the exception system while handling the exception. |
---|
[29c9b23] | 352 | |
---|
[8483c39a] | 353 | At runtime, no exception copy is made, as the stack is not unwound. Hence, the exception and |
---|
| 354 | any values on the stack remain in scope while the resumption is handled. |
---|
[4706098c] | 355 | |
---|
[8483c39a] | 356 | The exception searches walks the stack matching with the provided exception. |
---|
| 357 | It starts from the resuming function and proceeds to the base of the stack, |
---|
[1830a86] | 358 | from callee to caller. |
---|
| 359 | At each stack frame, a check is made for resumption handlers defined by the |
---|
| 360 | @catchResume@ clauses of a @try@ statement. |
---|
[4706098c] | 361 | \begin{cfa} |
---|
[4a36b344] | 362 | try { |
---|
[4706098c] | 363 | GUARDED_BLOCK |
---|
[8483c39a] | 364 | } catchResume (EXCEPTION_TYPE$\(_1\)$ [* NAME$\(_1\)$]) { |
---|
[4706098c] | 365 | HANDLER_BLOCK$\(_1\)$ |
---|
[8483c39a] | 366 | } catchResume (EXCEPTION_TYPE$\(_2\)$ [* NAME$\(_2\)$]) { |
---|
[4706098c] | 367 | HANDLER_BLOCK$\(_2\)$ |
---|
[4a36b344] | 368 | } |
---|
[4706098c] | 369 | \end{cfa} |
---|
[8483c39a] | 370 | Termination and resumption handlers may be intermixed in a @try@ |
---|
| 371 | statement but the kind of throw must match with kind of handler for it to be |
---|
| 372 | considered as a possible match. |
---|
| 373 | Like termination, when viewed on its own, a @try@ statement with |
---|
| 374 | @catchResume@ clauses simply executes the statements in the @GUARDED_BLOCK@, |
---|
| 375 | and when those are finished, the try statement finishes. |
---|
| 376 | |
---|
| 377 | However, while the guarded statements are being executed, including any invoked |
---|
| 378 | functions, a resumption exception may be thrown. If that exception is not handled by a try |
---|
| 379 | statement further up the stack, the handlers following the try block are now |
---|
| 380 | searched for a matching resumption exception-type from top to bottom. |
---|
| 381 | |
---|
| 382 | Like termination, exception matching checks each @catch@ clasue from top to bottom, if the representation of the thrown exception-type is |
---|
| 383 | the same or a descendant type of the exception types in the @catchResume@ clauses. If |
---|
| 384 | it is the same or a descendant of @EXCEPTION_TYPE@$_i$, then the optional @NAME@$_i$ is |
---|
| 385 | bound to a pointer to the exception and the statements in @HANDLER_BLOCK@$_i$ |
---|
| 386 | are executed. If control reaches the end of the handler, the exception is |
---|
| 387 | freed and control continues after the @throwResume@ statement. |
---|
| 388 | |
---|
| 389 | Like termination, if no resumption handler is found during the search, the |
---|
| 390 | default resumption handler visible at the raise is called, which is the best |
---|
| 391 | match at the according to \CFA's overloading rules. This function is passed the |
---|
| 392 | exception given to the raise. After the default handler is run, execution |
---|
| 393 | continues after the @throwResume@ statement. |
---|
| 394 | |
---|
| 395 | There is a global @defaultResumptionHandler@ that is polymorphic over all |
---|
| 396 | resumption and preforms a termination throw on the exception. |
---|
[1830a86] | 397 | The @defaultTerminationHandler@ for that throw is matched at the original |
---|
| 398 | throw statement (the resumption @throwResume@) and it can be customized by |
---|
| 399 | introducing a new or better match as well. |
---|
| 400 | |
---|
[8483c39a] | 401 | \subsection{Resumption Marking} |
---|
[1830a86] | 402 | A key difference between resumption and termination is that resumption does |
---|
[8483c39a] | 403 | not unwind the stack. A side effect is that when a handler is matched |
---|
| 404 | and run its try block (the guarded statements) and every try statement |
---|
[1830a86] | 405 | searched before it are still on the stack. This can lead to the recursive |
---|
| 406 | resumption problem. |
---|
| 407 | |
---|
| 408 | The recursive resumption problem is any situation where a resumption handler |
---|
| 409 | ends up being called while it is running. |
---|
| 410 | Consider a trivial case: |
---|
| 411 | \begin{cfa} |
---|
| 412 | try { |
---|
| 413 | throwResume (E &){}; |
---|
| 414 | } catchResume(E *) { |
---|
| 415 | throwResume (E &){}; |
---|
| 416 | } |
---|
| 417 | \end{cfa} |
---|
[8483c39a] | 418 | When this code is executed the guarded @throwResume@ starts a |
---|
| 419 | search and matches the handler in the @catchResume@ clause. The handler is |
---|
| 420 | called and placed on the stack on top of the try-block. The second throw in the handler |
---|
| 421 | searches the same try block and calls another instance of the |
---|
[1830a86] | 422 | same handler leading to an infinite loop. |
---|
| 423 | |
---|
[8483c39a] | 424 | While this situation is trivial and easy to avoid, much more complex cycles |
---|
[1830a86] | 425 | can form with multiple handlers and different exception types. |
---|
| 426 | |
---|
[8483c39a] | 427 | To prevent this case, examined try statements on the stack are marked, so that |
---|
| 428 | subsequent resumption searches skip over them and continue with the next unmarked section |
---|
| 429 | of the stack. |
---|
| 430 | Unmarking occurs when that exception is handled |
---|
| 431 | or the search completes without finding a handler. |
---|
[4a36b344] | 432 | |
---|
[02b73ea] | 433 | % This might need a diagram. But it is an important part of the justification |
---|
[4a36b344] | 434 | % of the design of the traversal order. |
---|
[8483c39a] | 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 | |
---|
| 454 | The resulting search can be understood by thinking about what is searched for |
---|
| 455 | termination. When a throw happens in a handler, a termination handler |
---|
[1830a86] | 456 | skips everything from the original throw to the original catch because that |
---|
[8483c39a] | 457 | part of the stack is unwound. A resumption handler skips the same |
---|
| 458 | section of stack because it is marked. |
---|
| 459 | A throw in a resumption default-handler performs the same search as the original |
---|
| 460 | @throwResume@ because for resumption nothing has been unwound. |
---|
[4706098c] | 461 | |
---|
[8483c39a] | 462 | The symmetry between resumption masking and termination searching is why this pattern was picked. Other patterns, |
---|
| 463 | such as marking just the handlers that caught, also work but the |
---|
| 464 | symmetry seems to match programmer intuition. |
---|
[4706098c] | 465 | |
---|
| 466 | \section{Conditional Catch} |
---|
[8483c39a] | 467 | Both termination and resumption handler-clauses can be given an additional |
---|
| 468 | condition to further control which exceptions is handled: |
---|
[4706098c] | 469 | \begin{cfa} |
---|
[8483c39a] | 470 | catch (EXCEPTION_TYPE [* NAME] @; CONDITION@) |
---|
[4706098c] | 471 | \end{cfa} |
---|
| 472 | First, the same semantics is used to match the exception type. Second, if the |
---|
| 473 | exception matches, @CONDITION@ is executed. The condition expression may |
---|
[8483c39a] | 474 | reference all names in the scope of the try block and @NAME@ |
---|
[1c1c180] | 475 | introduced in the handler clause. If the condition is true, then the handler |
---|
[1830a86] | 476 | matches. Otherwise, the exception search continues as if the exception type |
---|
| 477 | did not match. |
---|
[8483c39a] | 478 | |
---|
| 479 | Conditional catch allows fine-gain matching based on object values as well as exception types. |
---|
| 480 | For example, assume the exception hierarchy @OpenFailure@ $\rightarrow$ @CreateFailure@ and these exceptions are raised by function @open@. |
---|
| 481 | \begin{cfa} |
---|
| 482 | try { |
---|
| 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} |
---|
| 492 | Here, matching is very precise on the I/O exception and particular file with an open problem. |
---|
| 493 | This capability cannot be easily mimiced within the handler. |
---|
[4706098c] | 494 | \begin{cfa} |
---|
| 495 | try { |
---|
| 496 | f1 = open( ... ); |
---|
| 497 | f2 = open( ... ); |
---|
| 498 | ... |
---|
[8483c39a] | 499 | } catch( CreateFailure * f ) { |
---|
| 500 | if ( @fd( f ) == f1@ ) ... else // reraise |
---|
| 501 | } catch( OpenFailure * f ) { |
---|
| 502 | if ( @fd( f ) == f2@ ) ... else // reraise |
---|
[4706098c] | 503 | } |
---|
| 504 | \end{cfa} |
---|
[8483c39a] | 505 | When an exception @CreateFailure@ is raised, the first handler catches the |
---|
| 506 | derived exception and reraises it if the object is inappropriate. The reraise |
---|
| 507 | immediately terminates the current guarded block, which precludes the handler |
---|
| 508 | for the base exception @OpenFailure@ from consideration for object |
---|
| 509 | @f2@. Therefore, the ``catch first, then reraise'' approach is an incomplete |
---|
| 510 | substitute 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 |
---|
[29c9b23] | 515 | have rethrows/reraises instead.} |
---|
| 516 | |
---|
[4706098c] | 517 | Within the handler block or functions called from the handler block, it is |
---|
| 518 | possible to reraise the most recently caught exception with @throw@ or |
---|
[1830a86] | 519 | @throwResume@, respectively. |
---|
[4706098c] | 520 | \begin{cfa} |
---|
[29c9b23] | 521 | try { |
---|
| 522 | ... |
---|
| 523 | } catch( ... ) { |
---|
[1830a86] | 524 | ... throw; |
---|
[4706098c] | 525 | } catchResume( ... ) { |
---|
[1830a86] | 526 | ... throwResume; |
---|
[4706098c] | 527 | } |
---|
| 528 | \end{cfa} |
---|
| 529 | The only difference between a raise and a reraise is that reraise does not |
---|
| 530 | create a new exception; instead it continues using the current exception, \ie |
---|
| 531 | no allocation and copy. However the default handler is still set to the one |
---|
| 532 | visible at the raise point, and hence, for termination could refer to data that |
---|
| 533 | is part of an unwound stack frame. To prevent this problem, a new default |
---|
| 534 | handler is generated that does a program-level abort. |
---|
[8483c39a] | 535 | \PAB{I don't see how this is different from the normal throw/throwResume.} |
---|
[4a36b344] | 536 | |
---|
| 537 | \section{Finally Clauses} |
---|
[8483c39a] | 538 | Finally clauses are used to perform unconditional clean-up when leaving a |
---|
| 539 | scope and appear at the end of a try statement after any catch clauses: |
---|
[4706098c] | 540 | \begin{cfa} |
---|
[4a36b344] | 541 | try { |
---|
[4706098c] | 542 | GUARDED_BLOCK |
---|
[29c9b23] | 543 | } ... // any number or kind of handler clauses |
---|
| 544 | ... finally { |
---|
[4706098c] | 545 | FINALLY_BLOCK |
---|
[4a36b344] | 546 | } |
---|
[4706098c] | 547 | \end{cfa} |
---|
[29c9b23] | 548 | The @FINALLY_BLOCK@ is executed when the try statement is removed from the |
---|
[1830a86] | 549 | stack, including when the @GUARDED_BLOCK@ finishes, any termination handler |
---|
[8483c39a] | 550 | finishes, or during an unwind. |
---|
[29c9b23] | 551 | The only time the block is not executed is if the program is exited before |
---|
[1830a86] | 552 | the stack is unwound. |
---|
[4706098c] | 553 | |
---|
| 554 | Execution of the finally block should always finish, meaning control runs off |
---|
[8483c39a] | 555 | the end of the block. This requirement ensures execution always continues as if the |
---|
| 556 | finally clause is not present, \ie @finally@ is for cleanup not changing control |
---|
[1c1c180] | 557 | flow. Because of this requirement, local control flow out of the finally block |
---|
| 558 | is forbidden. The compiler precludes any @break@, @continue@, @fallthru@ or |
---|
[4706098c] | 559 | @return@ that causes control to leave the finally block. Other ways to leave |
---|
| 560 | the finally block, such as a long jump or termination are much harder to check, |
---|
[8483c39a] | 561 | and at best require additional run-time overhead, and so are |
---|
[1830a86] | 562 | discouraged. |
---|
| 563 | |
---|
| 564 | Not all languages with exceptions have finally clauses. Notably \Cpp does |
---|
[8483c39a] | 565 | without it as destructors serve a similar role. Although destructors and |
---|
| 566 | finally clauses can be used in many of the same areas, they have their own |
---|
[1830a86] | 567 | use cases like top-level functions and lambda functions with closures. |
---|
| 568 | Destructors take a bit more work to set up but are much easier to reuse while |
---|
[8483c39a] | 569 | finally clauses are good for one-off situations and can easily include local information. |
---|
[4a36b344] | 570 | |
---|
| 571 | \section{Cancellation} |
---|
[8483c39a] | 572 | \label{s:Cancellation} |
---|
| 573 | Cancellation is a stack-level abort, which can be thought of as an |
---|
| 574 | uncatchable termination. It unwinds the entire stack, and when |
---|
| 575 | possible, forwards the cancellation exception to a different stack. |
---|
[4706098c] | 576 | |
---|
[29c9b23] | 577 | Cancellation is not an exception operation like termination or resumption. |
---|
[4706098c] | 578 | There is no special statement for starting a cancellation; instead the standard |
---|
[1c1c180] | 579 | library function @cancel_stack@ is called passing an exception. Unlike a |
---|
[1830a86] | 580 | throw, this exception is not used in matching only to pass information about |
---|
[4706098c] | 581 | the cause of the cancellation. |
---|
[8483c39a] | 582 | (This semantics also means matching cannot fail so there is no default handler.) |
---|
[4706098c] | 583 | |
---|
[8483c39a] | 584 | After @cancel_stack@ is called, the exception is copied into the EHM's |
---|
| 585 | memory and the current stack is |
---|
[1830a86] | 586 | unwound. After that it depends one which stack is being cancelled. |
---|
[4706098c] | 587 | \begin{description} |
---|
| 588 | \item[Main Stack:] |
---|
| 589 | The main stack is the one used by the program main at the start of execution, |
---|
[8483c39a] | 590 | and is the only stack in a sequential program. Even in a concurrent program, |
---|
| 591 | the main stack is often used as the environment to start the concurrent threads. |
---|
[29c9b23] | 592 | Hence, when the main stack is cancelled there is nowhere else in the program |
---|
[8483c39a] | 593 | to go. Hence, after the main stack is unwound, there is a program-level abort. |
---|
[4706098c] | 594 | |
---|
| 595 | \item[Thread Stack:] |
---|
[8483c39a] | 596 | A thread stack is created for a \CFA @thread@ object or object that satisfies the |
---|
[1c1c180] | 597 | @is_thread@ trait. A thread only has two points of communication that must |
---|
[8483c39a] | 598 | happen: start and join. A thread must be running to perform a |
---|
| 599 | cancellation (a thread cannot cancel another thread). Therefore, a cancellation must |
---|
| 600 | occur after start and before join, so join is used |
---|
| 601 | for cancellation communication. |
---|
[29c9b23] | 602 | After the stack is unwound, the thread halts and waits for |
---|
| 603 | another thread to join with it. The joining thread checks for a cancellation, |
---|
[4706098c] | 604 | and if present, resumes exception @ThreadCancelled@. |
---|
| 605 | |
---|
[8483c39a] | 606 | \begin{sloppypar} |
---|
[4706098c] | 607 | There is a subtle difference between the explicit join (@join@ function) and |
---|
[8483c39a] | 608 | implicit join (from a @thread@'s destructor call). The explicit join takes the default |
---|
[4706098c] | 609 | handler (@defaultResumptionHandler@) from its calling context, which is used if |
---|
| 610 | the exception is not caught. The implicit join does a program abort instead. |
---|
[8483c39a] | 611 | \end{sloppypar} |
---|
[4706098c] | 612 | |
---|
[8483c39a] | 613 | \PAB{uC++ does not have these issues, but catch(...) is not working.} |
---|
| 614 | \begin{lstlisting}[language=uC++] |
---|
| 615 | #include <iostream> |
---|
| 616 | using namespace std; |
---|
| 617 | |
---|
| 618 | struct 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 | }; |
---|
| 647 | int 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.} |
---|
[29c9b23] | 660 | This semantics is for safety. If an unwind is triggered while another unwind |
---|
[8483c39a] | 661 | is underway only one of them can proceed as they both want to ``consume" the |
---|
[29c9b23] | 662 | stack. Letting both try to proceed leads to very undefined behaviour. |
---|
| 663 | Both termination and cancellation involve unwinding and, since the default |
---|
| 664 | @defaultResumptionHandler@ preforms a termination that could more easily |
---|
| 665 | happen in an implicate join inside a destructor. So there is an error message |
---|
| 666 | and an abort instead. |
---|
[8483c39a] | 667 | |
---|
[1830a86] | 668 | \todo{Perhaps have a more general disucssion of unwind collisions before |
---|
| 669 | this point.} |
---|
[29c9b23] | 670 | |
---|
[4260566] | 671 | The recommended way to avoid the abort is to handle the initial resumption |
---|
[29c9b23] | 672 | from the implicate join. If required you may put an explicate join inside a |
---|
| 673 | finally clause to disable the check and use the local |
---|
| 674 | @defaultResumptionHandler@ instead. |
---|
[4706098c] | 675 | |
---|
| 676 | \item[Coroutine Stack:] A coroutine stack is created for a @coroutine@ object |
---|
[1c1c180] | 677 | or object that satisfies the @is_coroutine@ trait. A coroutine only knows of |
---|
[1830a86] | 678 | two other coroutines, its starter and its last resumer. Of the two the last |
---|
| 679 | resumer has the tightest coupling to the coroutine it activated and the most |
---|
| 680 | up-to-date information. |
---|
| 681 | |
---|
| 682 | Hence, cancellation of the active coroutine is forwarded to the last resumer |
---|
| 683 | after the stack is unwound. When the resumer restarts, it resumes exception |
---|
[4706098c] | 684 | @CoroutineCancelled@, which is polymorphic over the coroutine type and has a |
---|
| 685 | pointer to the cancelled coroutine. |
---|
| 686 | |
---|
| 687 | The resume function also has an assertion that the @defaultResumptionHandler@ |
---|
| 688 | for the exception. So it will use the default handler like a regular throw. |
---|
| 689 | \end{description} |
---|
[8483c39a] | 690 | |
---|
| 691 | \PAB{You should have more test programs that compare \CFA EHM to uC++ EHM.} |
---|