[4706098c] | 1 | \chapter{Exception Features} |
---|
[553f8abe] | 2 | \label{c:features} |
---|
[4706098c] | 3 | |
---|
[4aba055] | 4 | This chapter covers the design and user interface of the \CFA EHM |
---|
| 5 | and begins with a general overview of EHMs. It is not a strict |
---|
| 6 | definition of all EHMs nor an exhaustive list of all possible features. |
---|
[21f2e92] | 7 | However it does cover the most common structure and features found in them. |
---|
[f6106a6] | 8 | |
---|
[4aba055] | 9 | \section{Overview of EHMs} |
---|
[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. |
---|
[4aba055] | 13 | \subsection{Raise / Handle} |
---|
[4260566] | 14 | An exception operation has two main parts: raise and handle. |
---|
[6071efc] | 15 | These terms are sometimes known as throw and catch but this work uses |
---|
[4260566] | 16 | throw/catch as a particular kind of raise/handle. |
---|
[4aba055] | 17 | These are the two parts that the user writes and may |
---|
[e3984a68] | 18 | be the only two pieces of the EHM that have any syntax in a language. |
---|
[4260566] | 19 | |
---|
[4aba055] | 20 | \paragraph{Raise} |
---|
[e3984a68] | 21 | The raise is the starting point for exception handling, |
---|
| 22 | by raising an exception, which passes it to |
---|
[f6106a6] | 23 | the EHM. |
---|
[4260566] | 24 | |
---|
[f6106a6] | 25 | Some well known examples include the @throw@ statements of \Cpp and Java and |
---|
[e3984a68] | 26 | the \code{Python}{raise} statement of Python. In real systems, a raise may |
---|
| 27 | perform some other work (such as memory management) but for the |
---|
[299b8b2] | 28 | purposes of this overview that can be ignored. |
---|
[4260566] | 29 | |
---|
[4aba055] | 30 | \paragraph{Handle} |
---|
[e3984a68] | 31 | The primary purpose of an EHM is to run some user code to handle a raised |
---|
| 32 | exception. This code is given, along with some other information, |
---|
| 33 | in a handler. |
---|
[f6106a6] | 34 | |
---|
| 35 | A handler has three common features: the previously mentioned user code, a |
---|
[e3984a68] | 36 | region of code it guards and an exception label/condition that matches |
---|
| 37 | against the raised exception. |
---|
[4aba055] | 38 | Only raises inside the guarded region and raising exceptions that match the |
---|
[f6106a6] | 39 | label can be handled by a given handler. |
---|
[6071efc] | 40 | If multiple handlers could can handle an exception, |
---|
[e3984a68] | 41 | EHMs define a rule to pick one, such as ``best match" or ``first found". |
---|
[4260566] | 42 | |
---|
[f6106a6] | 43 | The @try@ statements of \Cpp, Java and Python are common examples. All three |
---|
[f42a6b8] | 44 | also show another common feature of handlers, they are grouped by the guarded |
---|
| 45 | region. |
---|
[f6106a6] | 46 | |
---|
[4aba055] | 47 | \subsection{Propagation} |
---|
[de47a9d] | 48 | After an exception is raised comes what is usually the biggest step for the |
---|
[e3984a68] | 49 | EHM: finding and setting up the handler for execution. |
---|
| 50 | The propagation from raise to |
---|
[f6106a6] | 51 | handler can be broken up into three different tasks: searching for a handler, |
---|
[21f2e92] | 52 | matching against the handler and installing the handler. |
---|
[de47a9d] | 53 | |
---|
[4aba055] | 54 | \paragraph{Searching} |
---|
[f6106a6] | 55 | The EHM begins by searching for handlers that might be used to handle |
---|
[e3984a68] | 56 | the exception. |
---|
| 57 | The search will find handlers that have the raise site in their guarded |
---|
[f6106a6] | 58 | region. |
---|
[4aba055] | 59 | The search includes handlers in the current function, as well as any in |
---|
| 60 | callers on the stack that have the function call in their guarded region. |
---|
[f6106a6] | 61 | |
---|
[4aba055] | 62 | \paragraph{Matching} |
---|
[e3984a68] | 63 | Each handler found is with the raised exception. The exception |
---|
| 64 | label defines a condition that is used with the exception and decides if |
---|
[f6106a6] | 65 | there is a match or not. |
---|
[e3984a68] | 66 | % |
---|
[4aba055] | 67 | In languages where the first match is used, this step is intertwined with |
---|
[e3984a68] | 68 | searching; a match check is performed immediately after the search finds |
---|
| 69 | a handler. |
---|
[4260566] | 70 | |
---|
[4aba055] | 71 | \paragraph{Installing} |
---|
[e3984a68] | 72 | After a handler is chosen, it must be made ready to run. |
---|
[f6106a6] | 73 | The implementation can vary widely to fit with the rest of the |
---|
[de47a9d] | 74 | design of the EHM. The installation step might be trivial or it could be |
---|
[4260566] | 75 | the most expensive step in handling an exception. The latter tends to be the |
---|
| 76 | case when stack unwinding is involved. |
---|
[de47a9d] | 77 | |
---|
[6071efc] | 78 | If a matching handler is not guaranteed to be found, the EHM needs a |
---|
[e3984a68] | 79 | different course of action for this case. |
---|
[4aba055] | 80 | This situation only occurs with unchecked exceptions as checked exceptions |
---|
[f42a6b8] | 81 | (such as in Java) can make the guarantee. |
---|
[e3984a68] | 82 | The unhandled action is usually very general, such as aborting the program. |
---|
[4260566] | 83 | |
---|
[4aba055] | 84 | \paragraph{Hierarchy} |
---|
[f6106a6] | 85 | A common way to organize exceptions is in a hierarchical structure. |
---|
[4aba055] | 86 | This pattern comes from object-orientated languages where the |
---|
[4260566] | 87 | exception hierarchy is a natural extension of the object hierarchy. |
---|
| 88 | |
---|
[e3984a68] | 89 | Consider the following exception hierarchy: |
---|
[4706098c] | 90 | \begin{center} |
---|
[6a8208cb] | 91 | \input{exception-hierarchy} |
---|
[4706098c] | 92 | \end{center} |
---|
[4aba055] | 93 | A handler labeled with any given exception can handle exceptions of that |
---|
[4260566] | 94 | type or any child type of that exception. The root of the exception hierarchy |
---|
[f42a6b8] | 95 | (here \code{C}{exception}) acts as a catch-all, leaf types catch single types |
---|
[4260566] | 96 | and the exceptions in the middle can be used to catch different groups of |
---|
| 97 | related exceptions. |
---|
| 98 | |
---|
| 99 | This system has some notable advantages, such as multiple levels of grouping, |
---|
[f42a6b8] | 100 | the ability for libraries to add new exception types and the isolation |
---|
[f6106a6] | 101 | between different sub-hierarchies. |
---|
| 102 | This design is used in \CFA even though it is not a object-orientated |
---|
[a6c45c6] | 103 | language; so different tools are used to create the hierarchy. |
---|
[4260566] | 104 | |
---|
| 105 | % Could I cite the rational for the Python IO exception rework? |
---|
| 106 | |
---|
[4aba055] | 107 | \subsection{Completion} |
---|
[6071efc] | 108 | After the handler has finished, the entire exception operation has to complete |
---|
[f6106a6] | 109 | and continue executing somewhere else. This step is usually simple, |
---|
| 110 | both logically and in its implementation, as the installation of the handler |
---|
| 111 | is usually set up to do most of the work. |
---|
[de47a9d] | 112 | |
---|
[e3984a68] | 113 | The EHM can return control to many different places, where |
---|
[4aba055] | 114 | the most common are after the handler definition (termination) |
---|
| 115 | and after the raise (resumption). |
---|
[4260566] | 116 | |
---|
[4aba055] | 117 | \subsection{Communication} |
---|
[887fc79] | 118 | For effective exception handling, additional information is often passed |
---|
[4aba055] | 119 | from the raise to the handler and back again. |
---|
[e3984a68] | 120 | So far, only communication of the exceptions' identity is covered. |
---|
| 121 | A common communication method for adding information to an exception |
---|
| 122 | is putting fields into the exception instance |
---|
[4aba055] | 123 | and giving the handler access to them. |
---|
[e3984a68] | 124 | % You can either have pointers/references in the exception, or have p/rs to |
---|
| 125 | % the exception when it doesn't have to be copied. |
---|
| 126 | Passing references or pointers allows data at the raise location to be |
---|
| 127 | updated, passing information in both directions. |
---|
[4260566] | 128 | |
---|
| 129 | \section{Virtuals} |
---|
[3b8acfb] | 130 | \label{s:virtuals} |
---|
[f6106a6] | 131 | Virtual types and casts are not part of \CFA's EHM nor are they required for |
---|
[e3984a68] | 132 | an EHM. |
---|
| 133 | However, one of the best ways to support an exception hierarchy |
---|
[4aba055] | 134 | is via a virtual hierarchy and dispatch system. |
---|
[f42a6b8] | 135 | Ideally, the virtual system would have been part of \CFA before the work |
---|
[a6c45c6] | 136 | on exception handling began, but unfortunately it was not. |
---|
[4aba055] | 137 | Hence, only the features and framework needed for the EHM were |
---|
[e3984a68] | 138 | designed and implemented for this thesis. |
---|
| 139 | Other features were considered to ensure that |
---|
[4aba055] | 140 | the structure could accommodate other desirable features in the future |
---|
[e3984a68] | 141 | but are not implemented. |
---|
| 142 | The rest of this section only discusses the implemented subset of the |
---|
[f42a6b8] | 143 | virtual system design. |
---|
[4260566] | 144 | |
---|
| 145 | The virtual system supports multiple ``trees" of types. Each tree is |
---|
| 146 | a simple hierarchy with a single root type. Each type in a tree has exactly |
---|
[f6106a6] | 147 | one parent -- except for the root type which has zero parents -- and any |
---|
[4260566] | 148 | number of children. |
---|
| 149 | Any type that belongs to any of these trees is called a virtual type. |
---|
| 150 | % A type's ancestors are its parent and its parent's ancestors. |
---|
| 151 | % The root type has no ancestors. |
---|
[4aba055] | 152 | % A type's descendants are its children and its children's descendants. |
---|
[4260566] | 153 | |
---|
[e3984a68] | 154 | For the purposes of illistration, a proposed -- but unimplemented syntax -- |
---|
| 155 | will be used. Each virtual type is repersented by a trait with an annotation |
---|
| 156 | that makes it a virtual type. This annotation is empty for a root type, which |
---|
| 157 | creates a new tree: |
---|
| 158 | \begin{cfa} |
---|
| 159 | trait root_type(T) virtual() {} |
---|
| 160 | \end{cfa} |
---|
| 161 | The annotation may also refer to any existing virtual type to make this new |
---|
| 162 | type a child of that type and part of the same tree. The parent may itself |
---|
| 163 | be a child or a root type and may have any number of existing children. |
---|
| 164 | \begin{cfa} |
---|
| 165 | trait child_a(T) virtual(root_type) {} |
---|
| 166 | trait grandchild(T) virtual(child_a) {} |
---|
| 167 | trait child_b(T) virtual(root_type) {} |
---|
| 168 | \end{cfa} |
---|
| 169 | \todo{Update the diagram in vtable.fig to show the new type tree.} |
---|
[4aba055] | 170 | |
---|
[e3984a68] | 171 | Every virtual type also has a list of virtual members and a unique id, |
---|
| 172 | both are stored in a virtual table. |
---|
| 173 | Every instance of a virtual type also has a pointer to a virtual table stored |
---|
| 174 | in it, although there is no per-type virtual table as in many other languages. |
---|
[4260566] | 175 | |
---|
[e3984a68] | 176 | The list of virtual members is built up down the tree. Every virtual type |
---|
| 177 | inherits the list of virtual members from its parent and may add more |
---|
| 178 | virtual members to the end of the list which are passed on to its children. |
---|
| 179 | Again, using the unimplemented syntax this might look like: |
---|
| 180 | \begin{cfa} |
---|
| 181 | trait root_type(T) virtual() { |
---|
| 182 | const char * to_string(T const & this); |
---|
| 183 | unsigned int size; |
---|
| 184 | } |
---|
| 185 | |
---|
| 186 | trait child_type(T) virtual(root_type) { |
---|
| 187 | char * irrelevant_function(int, char); |
---|
| 188 | } |
---|
| 189 | \end{cfa} |
---|
| 190 | % Consider adding a diagram, but we might be good with the explanation. |
---|
| 191 | |
---|
| 192 | As @child_type@ is a child of @root_type@ it has the virtual members of |
---|
| 193 | @root_type@ (@to_string@ and @size@) as well as the one it declared |
---|
| 194 | (@irrelivant_function@). |
---|
| 195 | |
---|
| 196 | It is important to note that these are virtual members, and may contain |
---|
| 197 | arbitrary fields, functions or otherwise. |
---|
| 198 | The names ``size" and ``align" are reserved for the size and alignment of the |
---|
| 199 | virtual type, and are always automatically initialized as such. |
---|
| 200 | The other special case are uses of the trait's polymorphic argument |
---|
| 201 | (@T@ in the example), which are always updated to refer to the current |
---|
| 202 | virtual type. This allows functions that refer to to polymorphic argument |
---|
| 203 | to act as traditional virtual methods (@to_string@ in the example), as the |
---|
| 204 | object can always be passed to a virtual method in its virtual table. |
---|
[4260566] | 205 | |
---|
[f6106a6] | 206 | Up until this point the virtual system is similar to ones found in |
---|
[e3984a68] | 207 | object-oriented languages but this is where \CFA diverges. |
---|
| 208 | Objects encapsulate a single set of methods in each type, |
---|
| 209 | universally across the entire program, |
---|
| 210 | and indeed all programs that use that type definition. |
---|
| 211 | The only way to change any method is to inherit and define a new type with |
---|
| 212 | its own universal implementation. In this sense, |
---|
| 213 | these object-oriented types are ``closed" and cannot be altered. |
---|
| 214 | % Because really they are class oriented. |
---|
| 215 | |
---|
| 216 | In \CFA, types do not encapsulate any code. |
---|
| 217 | Whether or not satisfies any given assertion, and hence any trait, is |
---|
| 218 | context sensitive. Types can begin to satisfy a trait, stop satisfying it or |
---|
| 219 | satisfy the same trait at any lexical location in the program. |
---|
| 220 | In this sense, an type's implementation in the set of functions and variables |
---|
| 221 | that allow it to satisfy a trait is ``open" and can change |
---|
| 222 | throughout the program. |
---|
[4aba055] | 223 | This capability means it is impossible to pick a single set of functions |
---|
[e3984a68] | 224 | that represent a type's implementation across a program. |
---|
[f6106a6] | 225 | |
---|
| 226 | \CFA side-steps this issue by not having a single virtual table for each |
---|
[4aba055] | 227 | type. A user can define virtual tables that are filled in at their |
---|
| 228 | declaration and given a name. Anywhere that name is visible, even if it is |
---|
[e3984a68] | 229 | defined locally inside a function (although in this case the user must ensure |
---|
| 230 | it outlives any objects that use it), it can be used. |
---|
[4aba055] | 231 | Specifically, a virtual type is ``bound" to a virtual table that |
---|
[08e75215] | 232 | sets the virtual members for that object. The virtual members can be accessed |
---|
| 233 | through the object. |
---|
[4706098c] | 234 | |
---|
[ed4d7c1] | 235 | This means virtual tables are declared and named in \CFA. |
---|
| 236 | They are declared as variables, using the type |
---|
| 237 | @vtable(VIRTUAL_TYPE)@ and any valid name. For example: |
---|
| 238 | \begin{cfa} |
---|
| 239 | vtable(virtual_type_name) table_name; |
---|
| 240 | \end{cfa} |
---|
| 241 | |
---|
| 242 | Like any variable they may be forward declared with the @extern@ keyword. |
---|
| 243 | Forward declaring virtual tables is relatively common. |
---|
| 244 | Many virtual types have an ``obvious" implementation that works in most |
---|
| 245 | cases. |
---|
| 246 | A pattern that has appeared in the early work using virtuals is to |
---|
| 247 | implement a virtual table with the the obvious definition and place a forward |
---|
| 248 | declaration of it in the header beside the definition of the virtual type. |
---|
| 249 | |
---|
| 250 | Even on the full declaration, no initializer should be used. |
---|
| 251 | Initialization is automatic. |
---|
| 252 | The type id and special virtual members ``size" and ``align" only depend on |
---|
| 253 | the virtual type, which is fixed given the type of the virtual table and |
---|
| 254 | so the compiler fills in a fixed value. |
---|
| 255 | The other virtual members are resolved, using the best match to the member's |
---|
| 256 | name and type, in the same context as the virtual table is declared using |
---|
| 257 | \CFA's normal resolution rules. |
---|
| 258 | |
---|
[4706098c] | 259 | While much of the virtual infrastructure is created, it is currently only used |
---|
| 260 | internally for exception handling. The only user-level feature is the virtual |
---|
[21f2e92] | 261 | cast, which is the same as the \Cpp \code{C++}{dynamic_cast}. |
---|
[7eb6eb5] | 262 | \label{p:VirtualCast} |
---|
[4706098c] | 263 | \begin{cfa} |
---|
[4a36b344] | 264 | (virtual TYPE)EXPRESSION |
---|
[4706098c] | 265 | \end{cfa} |
---|
[29c9b23] | 266 | Note, the syntax and semantics matches a C-cast, rather than the function-like |
---|
| 267 | \Cpp syntax for special casts. Both the type of @EXPRESSION@ and @TYPE@ must be |
---|
| 268 | a pointer to a virtual type. |
---|
[de47a9d] | 269 | The cast dynamically checks if the @EXPRESSION@ type is the same or a sub-type |
---|
[29c9b23] | 270 | of @TYPE@, and if true, returns a pointer to the |
---|
[4706098c] | 271 | @EXPRESSION@ object, otherwise it returns @0p@ (null pointer). |
---|
| 272 | |
---|
[ed4d7c1] | 273 | \section{Exceptions} |
---|
| 274 | |
---|
| 275 | The syntax for declaring an exception is the same as declaring a structure |
---|
| 276 | except the keyword that is swapped out: |
---|
| 277 | \begin{cfa} |
---|
| 278 | exception TYPE_NAME { |
---|
| 279 | FIELDS |
---|
| 280 | }; |
---|
| 281 | \end{cfa} |
---|
| 282 | |
---|
| 283 | Fields are filled in the same way as a structure as well. However an extra |
---|
| 284 | field is added, this field contains the pointer to the virtual table. |
---|
| 285 | It must be explicitly initialised by the user when the exception is |
---|
| 286 | constructed. |
---|
| 287 | |
---|
| 288 | Here is an example of declaring an exception type along with a virtual table, |
---|
| 289 | assuming the exception has an ``obvious" implementation and a default |
---|
| 290 | virtual table makes sense. |
---|
| 291 | |
---|
| 292 | \begin{minipage}[t]{0.4\textwidth} |
---|
| 293 | Header: |
---|
| 294 | \begin{cfa} |
---|
| 295 | exception Example { |
---|
| 296 | int data; |
---|
| 297 | }; |
---|
| 298 | |
---|
| 299 | extern vtable(Example) |
---|
| 300 | example_base_vtable; |
---|
| 301 | \end{cfa} |
---|
| 302 | \end{minipage} |
---|
| 303 | \begin{minipage}[t]{0.6\textwidth} |
---|
| 304 | Source: |
---|
| 305 | \begin{cfa} |
---|
| 306 | vtable(Example) example_base_vtable |
---|
| 307 | \end{cfa} |
---|
| 308 | \vfil |
---|
| 309 | \end{minipage} |
---|
| 310 | |
---|
| 311 | %\subsection{Exception Details} |
---|
| 312 | If one is only raising and handling exceptions, that is the only interface |
---|
| 313 | that is needed. However it is actually a short hand for a more complex |
---|
| 314 | trait based interface. |
---|
[4a36b344] | 315 | |
---|
[ed4d7c1] | 316 | The language views exceptions through a series of traits, |
---|
[1c1c180] | 317 | if a type satisfies them, then it can be used as an exception. The following |
---|
[4706098c] | 318 | is the base trait all exceptions need to match. |
---|
| 319 | \begin{cfa} |
---|
| 320 | trait is_exception(exceptT &, virtualT &) { |
---|
[a6c45c6] | 321 | // Numerous imaginary assertions. |
---|
[02b73ea] | 322 | }; |
---|
[4706098c] | 323 | \end{cfa} |
---|
[29c9b23] | 324 | The trait is defined over two types, the exception type and the virtual table |
---|
[4aba055] | 325 | type. Each exception type should have a single virtual table type. |
---|
| 326 | There are no actual assertions in this trait because the trait system |
---|
| 327 | cannot express them yet (adding such assertions would be part of |
---|
[a6c45c6] | 328 | completing the virtual system). The imaginary assertions would probably come |
---|
| 329 | from a trait defined by the virtual system, and state that the exception type |
---|
[f42a6b8] | 330 | is a virtual type, is a descendant of @exception_t@ (the base exception type) |
---|
[e3984a68] | 331 | and allow the user to find the virtual table type. |
---|
[29c9b23] | 332 | |
---|
| 333 | % I did have a note about how it is the programmer's responsibility to make |
---|
| 334 | % sure the function is implemented correctly. But this is true of every |
---|
[de47a9d] | 335 | % similar system I know of (except Agda's I guess) so I took it out. |
---|
| 336 | |
---|
[f6106a6] | 337 | There are two more traits for exceptions defined as follows: |
---|
[4706098c] | 338 | \begin{cfa} |
---|
[02b73ea] | 339 | trait is_termination_exception( |
---|
[4706098c] | 340 | exceptT &, virtualT & | is_exception(exceptT, virtualT)) { |
---|
[29c9b23] | 341 | void defaultTerminationHandler(exceptT &); |
---|
[02b73ea] | 342 | }; |
---|
| 343 | |
---|
| 344 | trait is_resumption_exception( |
---|
[4706098c] | 345 | exceptT &, virtualT & | is_exception(exceptT, virtualT)) { |
---|
[29c9b23] | 346 | void defaultResumptionHandler(exceptT &); |
---|
[02b73ea] | 347 | }; |
---|
[4706098c] | 348 | \end{cfa} |
---|
[4aba055] | 349 | Both traits ensure a pair of types are an exception type, its virtual table |
---|
[f42a6b8] | 350 | type |
---|
[f6106a6] | 351 | and defines one of the two default handlers. The default handlers are used |
---|
[df24d37] | 352 | as fallbacks and are discussed in detail in \vref{s:ExceptionHandling}. |
---|
[de47a9d] | 353 | |
---|
[f6106a6] | 354 | However, all three of these traits can be tricky to use directly. |
---|
| 355 | While there is a bit of repetition required, |
---|
[de47a9d] | 356 | the largest issue is that the virtual table type is mangled and not in a user |
---|
[f6106a6] | 357 | facing way. So these three macros are provided to wrap these traits to |
---|
| 358 | simplify referring to the names: |
---|
[f42a6b8] | 359 | @IS_EXCEPTION@, @IS_TERMINATION_EXCEPTION@ and @IS_RESUMPTION_EXCEPTION@. |
---|
[1830a86] | 360 | |
---|
[f6106a6] | 361 | All three take one or two arguments. The first argument is the name of the |
---|
| 362 | exception type. The macro passes its unmangled and mangled form to the trait. |
---|
[1830a86] | 363 | The second (optional) argument is a parenthesized list of polymorphic |
---|
[f6106a6] | 364 | arguments. This argument is only used with polymorphic exceptions and the |
---|
| 365 | list is be passed to both types. |
---|
| 366 | In the current set-up, the two types always have the same polymorphic |
---|
| 367 | arguments so these macros can be used without losing flexibility. |
---|
[29c9b23] | 368 | |
---|
| 369 | For example consider a function that is polymorphic over types that have a |
---|
| 370 | defined arithmetic exception: |
---|
| 371 | \begin{cfa} |
---|
[de47a9d] | 372 | forall(Num | IS_EXCEPTION(Arithmetic, (Num))) |
---|
[29c9b23] | 373 | void some_math_function(Num & left, Num & right); |
---|
| 374 | \end{cfa} |
---|
[4706098c] | 375 | |
---|
[1830a86] | 376 | \section{Exception Handling} |
---|
[f6106a6] | 377 | \label{s:ExceptionHandling} |
---|
[4aba055] | 378 | As stated, |
---|
[21f2e92] | 379 | \CFA provides two kinds of exception handling: termination and resumption. |
---|
[f6106a6] | 380 | These twin operations are the core of \CFA's exception handling mechanism. |
---|
[e3984a68] | 381 | This section covers the general patterns shared by the two operations and |
---|
| 382 | then goes on to cover the details each individual operation. |
---|
[de47a9d] | 383 | |
---|
[f6106a6] | 384 | Both operations follow the same set of steps. |
---|
[e3984a68] | 385 | First, a user raises an exception. |
---|
| 386 | Second, the exception propagates up the stack, searching for a handler. |
---|
| 387 | Third, if a handler is found, the exception is caught and the handler is run. |
---|
[4aba055] | 388 | After that control continues at a raise-dependent location. |
---|
[e3984a68] | 389 | As an alternate to the third step, |
---|
| 390 | if a handler is not found, a default handler is run and, if it returns, |
---|
| 391 | then control |
---|
[4aba055] | 392 | continues after the raise. |
---|
[f6106a6] | 393 | |
---|
[e3984a68] | 394 | The differences between the two operations include how propagation is |
---|
| 395 | performed, where excecution after an exception is handler |
---|
| 396 | and which default handler is run. |
---|
[1830a86] | 397 | |
---|
[4706098c] | 398 | \subsection{Termination} |
---|
| 399 | \label{s:Termination} |
---|
[e3984a68] | 400 | Termination handling is the familiar kind of handling |
---|
| 401 | and used in most programming |
---|
[1830a86] | 402 | languages with exception handling. |
---|
[4aba055] | 403 | It is a dynamic, non-local goto. If the raised exception is matched and |
---|
| 404 | handled, the stack is unwound and control (usually) continues in the function |
---|
[f6106a6] | 405 | on the call stack that defined the handler. |
---|
| 406 | Termination is commonly used when an error has occurred and recovery is |
---|
| 407 | impossible locally. |
---|
[1830a86] | 408 | |
---|
| 409 | % (usually) Control can continue in the current function but then a different |
---|
| 410 | % control flow construct should be used. |
---|
[4706098c] | 411 | |
---|
[f6106a6] | 412 | A termination raise is started with the @throw@ statement: |
---|
[4706098c] | 413 | \begin{cfa} |
---|
[4a36b344] | 414 | throw EXPRESSION; |
---|
[4706098c] | 415 | \end{cfa} |
---|
[29c9b23] | 416 | The expression must return a reference to a termination exception, where the |
---|
[f6106a6] | 417 | termination exception is any type that satisfies the trait |
---|
| 418 | @is_termination_exception@ at the call site. |
---|
[4aba055] | 419 | Through \CFA's trait system, the trait functions are implicitly passed into the |
---|
[e3984a68] | 420 | throw code for use by the EHM. |
---|
[f6106a6] | 421 | A new @defaultTerminationHandler@ can be defined in any scope to |
---|
[e3984a68] | 422 | change the throw's behaviour when a handler is not found (see below). |
---|
[de47a9d] | 423 | |
---|
[4aba055] | 424 | The throw copies the provided exception into managed memory to ensure |
---|
[21f2e92] | 425 | the exception is not destroyed if the stack is unwound. |
---|
[f6106a6] | 426 | It is the user's responsibility to ensure the original exception is cleaned |
---|
[4aba055] | 427 | up whether the stack is unwound or not. Allocating it on the stack is |
---|
[f6106a6] | 428 | usually sufficient. |
---|
[de47a9d] | 429 | |
---|
[4aba055] | 430 | % How to say propagation starts, its first sub-step is the search. |
---|
| 431 | Then propagation starts with the search. \CFA uses a ``first match" rule so |
---|
[e3984a68] | 432 | matching is performed with the copied exception as the search key. |
---|
| 433 | It starts from the raise site and proceeds towards base of the stack, |
---|
[1830a86] | 434 | from callee to caller. |
---|
[e3984a68] | 435 | At each stack frame, a check is made for termination handlers defined by the |
---|
[1830a86] | 436 | @catch@ clauses of a @try@ statement. |
---|
[4706098c] | 437 | \begin{cfa} |
---|
[4a36b344] | 438 | try { |
---|
[4706098c] | 439 | GUARDED_BLOCK |
---|
[f6106a6] | 440 | } catch (EXCEPTION_TYPE$\(_1\)$ * [NAME$\(_1\)$]) { |
---|
[4706098c] | 441 | HANDLER_BLOCK$\(_1\)$ |
---|
[f6106a6] | 442 | } catch (EXCEPTION_TYPE$\(_2\)$ * [NAME$\(_2\)$]) { |
---|
[4706098c] | 443 | HANDLER_BLOCK$\(_2\)$ |
---|
[4a36b344] | 444 | } |
---|
[4706098c] | 445 | \end{cfa} |
---|
[4aba055] | 446 | When viewed on its own, a try statement simply executes the statements |
---|
[e3984a68] | 447 | in the \snake{GUARDED_BLOCK} and when those are finished, |
---|
[4aba055] | 448 | the try statement finishes. |
---|
[de47a9d] | 449 | |
---|
| 450 | However, while the guarded statements are being executed, including any |
---|
[4aba055] | 451 | invoked functions, all the handlers in these statements are included in the |
---|
| 452 | search path. |
---|
[e3984a68] | 453 | Hence, if a termination exception is raised, these handlers may be matched |
---|
[4aba055] | 454 | against the exception and may handle it. |
---|
[f6106a6] | 455 | |
---|
| 456 | Exception matching checks the handler in each catch clause in the order |
---|
[4aba055] | 457 | they appear, top to bottom. If the representation of the raised exception type |
---|
[e3984a68] | 458 | is the same or a descendant of @EXCEPTION_TYPE@$_i$, then @NAME@$_i$ |
---|
[21f2e92] | 459 | (if provided) is |
---|
| 460 | bound to a pointer to the exception and the statements in @HANDLER_BLOCK@$_i$ |
---|
| 461 | are executed. If control reaches the end of the handler, the exception is |
---|
[de47a9d] | 462 | freed and control continues after the try statement. |
---|
[4706098c] | 463 | |
---|
[e3984a68] | 464 | If no termination handler is found during the search, then the default handler |
---|
| 465 | (\defaultTerminationHandler) visible at the raise statement is called. |
---|
| 466 | Through \CFA's trait system the best match at the raise statement is used. |
---|
[4aba055] | 467 | This function is run and is passed the copied exception. |
---|
[e3984a68] | 468 | If the default handler finishes, control continues after the raise statement. |
---|
[1830a86] | 469 | |
---|
[f6106a6] | 470 | There is a global @defaultTerminationHandler@ that is polymorphic over all |
---|
[4aba055] | 471 | termination exception types. |
---|
[f6106a6] | 472 | The global default termination handler performs a cancellation |
---|
[e3984a68] | 473 | (as described in \vref{s:Cancellation}) |
---|
| 474 | on the current stack with the copied exception. |
---|
| 475 | Since it is so general, a more specific handler can be defined, |
---|
| 476 | overriding the default behaviour for the specific exception types. |
---|
[4706098c] | 477 | |
---|
| 478 | \subsection{Resumption} |
---|
| 479 | \label{s:Resumption} |
---|
| 480 | |
---|
[e3984a68] | 481 | Resumption exception handling is less familar form of exception handling, |
---|
| 482 | but is |
---|
[f6106a6] | 483 | just as old~\cite{Goodenough75} and is simpler in many ways. |
---|
| 484 | It is a dynamic, non-local function call. If the raised exception is |
---|
[e3984a68] | 485 | matched, a closure is taken from up the stack and executed, |
---|
[4aba055] | 486 | after which the raising function continues executing. |
---|
| 487 | The common uses for resumption exceptions include |
---|
| 488 | potentially repairable errors, where execution can continue in the same |
---|
| 489 | function once the error is corrected, and |
---|
| 490 | ignorable events, such as logging where nothing needs to happen and control |
---|
[e3984a68] | 491 | should always continue from the raise site. |
---|
| 492 | |
---|
| 493 | Except for the changes to fit into that pattern, resumption exception |
---|
| 494 | handling is symmetric with termination exception handling, by design |
---|
| 495 | (see \autoref{s:Termination}). |
---|
[8483c39a] | 496 | |
---|
[4706098c] | 497 | A resumption raise is started with the @throwResume@ statement: |
---|
| 498 | \begin{cfa} |
---|
[4a36b344] | 499 | throwResume EXPRESSION; |
---|
[4706098c] | 500 | \end{cfa} |
---|
[4aba055] | 501 | \todo{Decide on a final set of keywords and use them everywhere.} |
---|
[e3984a68] | 502 | It works much the same way as the termination raise, except the |
---|
| 503 | type must satisfy the \snake{is_resumption_exception} that uses the |
---|
| 504 | default handler: \defaultResumptionHandler. |
---|
| 505 | This can be specialized for particular exception types. |
---|
| 506 | |
---|
| 507 | At run-time, no exception copy is made. Since |
---|
| 508 | resumption does not unwind the stack nor otherwise remove values from the |
---|
| 509 | current scope, there is no need to manage memory to keep the exception |
---|
| 510 | allocated. |
---|
| 511 | |
---|
| 512 | Then propagation starts with the search, |
---|
| 513 | following the same search path as termination, |
---|
| 514 | from the raise site to the base of stack and top of try statement to bottom. |
---|
| 515 | However, the handlers on try statements are defined by @catchResume@ clauses. |
---|
[4706098c] | 516 | \begin{cfa} |
---|
[4a36b344] | 517 | try { |
---|
[4706098c] | 518 | GUARDED_BLOCK |
---|
[f6106a6] | 519 | } catchResume (EXCEPTION_TYPE$\(_1\)$ * [NAME$\(_1\)$]) { |
---|
[4706098c] | 520 | HANDLER_BLOCK$\(_1\)$ |
---|
[f6106a6] | 521 | } catchResume (EXCEPTION_TYPE$\(_2\)$ * [NAME$\(_2\)$]) { |
---|
[4706098c] | 522 | HANDLER_BLOCK$\(_2\)$ |
---|
[4a36b344] | 523 | } |
---|
[4706098c] | 524 | \end{cfa} |
---|
[f42a6b8] | 525 | Note that termination handlers and resumption handlers may be used together |
---|
[f6106a6] | 526 | in a single try statement, intermixing @catch@ and @catchResume@ freely. |
---|
[4aba055] | 527 | Each type of handler only interacts with exceptions from the matching |
---|
| 528 | kind of raise. |
---|
[e3984a68] | 529 | Like @catch@ clauses, @catchResume@ clauses have no effect if an exception |
---|
| 530 | is not raised. |
---|
[f42a6b8] | 531 | |
---|
[e3984a68] | 532 | The matching rules are exactly the same as well. |
---|
| 533 | The first major difference here is that after |
---|
| 534 | @EXCEPTION_TYPE@$_i$ is matched and @NAME@$_i$ is bound to the exception, |
---|
| 535 | @HANDLER_BLOCK@$_i$ is executed right away without first unwinding the stack. |
---|
| 536 | After the block has finished running control jumps to the raise site, where |
---|
| 537 | the just handled exception came from, and continues executing after it, |
---|
| 538 | not after the try statement. |
---|
[1830a86] | 539 | |
---|
[f6106a6] | 540 | \subsubsection{Resumption Marking} |
---|
[df24d37] | 541 | \label{s:ResumptionMarking} |
---|
[1830a86] | 542 | A key difference between resumption and termination is that resumption does |
---|
[e3984a68] | 543 | not unwind the stack. A side effect is that, when a handler is matched |
---|
| 544 | and run, its try block (the guarded statements) and every try statement |
---|
[4aba055] | 545 | searched before it are still on the stack. There presence can lead to |
---|
[f42a6b8] | 546 | the recursive resumption problem. |
---|
[e3984a68] | 547 | \todo{Is there a citation for the recursive resumption problem?} |
---|
[1830a86] | 548 | |
---|
| 549 | The recursive resumption problem is any situation where a resumption handler |
---|
| 550 | ends up being called while it is running. |
---|
| 551 | Consider a trivial case: |
---|
| 552 | \begin{cfa} |
---|
| 553 | try { |
---|
| 554 | throwResume (E &){}; |
---|
| 555 | } catchResume(E *) { |
---|
| 556 | throwResume (E &){}; |
---|
| 557 | } |
---|
| 558 | \end{cfa} |
---|
[4aba055] | 559 | When this code is executed, the guarded @throwResume@ starts a |
---|
| 560 | search and matches the handler in the @catchResume@ clause. This |
---|
[e3984a68] | 561 | call is placed on the stack above the try-block. |
---|
| 562 | Now the second raise in the handler searches the same try block, |
---|
| 563 | matches again and then puts another instance of the |
---|
[4aba055] | 564 | same handler on the stack leading to infinite recursion. |
---|
[1830a86] | 565 | |
---|
[f42a6b8] | 566 | While this situation is trivial and easy to avoid, much more complex cycles |
---|
| 567 | can form with multiple handlers and different exception types. |
---|
[e3984a68] | 568 | To prevent all of these cases, each try statement is ``marked" from the |
---|
| 569 | time the exception search reaches it to either when a handler completes |
---|
| 570 | handling that exception or when the search reaches the base |
---|
[4aba055] | 571 | of the stack. |
---|
| 572 | While a try statement is marked, its handlers are never matched, effectively |
---|
[21f2e92] | 573 | skipping over it to the next try statement. |
---|
[4a36b344] | 574 | |
---|
[6a8208cb] | 575 | \begin{center} |
---|
| 576 | \input{stack-marking} |
---|
| 577 | \end{center} |
---|
[de47a9d] | 578 | |
---|
[4aba055] | 579 | There are other sets of marking rules that could be used, |
---|
| 580 | for instance, marking just the handlers that caught the exception, |
---|
| 581 | would also prevent recursive resumption. |
---|
[e3984a68] | 582 | However, the rules selected mirrors what happens with termination, |
---|
| 583 | so this reduces the amount of rules and patterns a programmer has to know. |
---|
[4706098c] | 584 | |
---|
[e3984a68] | 585 | The marked try statements are the ones that would be removed from |
---|
| 586 | the stack for a termination exception, \ie those on the stack |
---|
[4aba055] | 587 | between the handler and the raise statement. |
---|
| 588 | This symmetry applies to the default handler as well, as both kinds of |
---|
| 589 | default handlers are run at the raise statement, rather than (physically |
---|
| 590 | or logically) at the bottom of the stack. |
---|
| 591 | % In early development having the default handler happen after |
---|
| 592 | % unmarking was just more useful. We assume that will continue. |
---|
[4706098c] | 593 | |
---|
| 594 | \section{Conditional Catch} |
---|
[de47a9d] | 595 | Both termination and resumption handler clauses can be given an additional |
---|
| 596 | condition to further control which exceptions they handle: |
---|
[4706098c] | 597 | \begin{cfa} |
---|
[f6106a6] | 598 | catch (EXCEPTION_TYPE * [NAME] ; CONDITION) |
---|
[4706098c] | 599 | \end{cfa} |
---|
| 600 | First, the same semantics is used to match the exception type. Second, if the |
---|
| 601 | exception matches, @CONDITION@ is executed. The condition expression may |
---|
[de47a9d] | 602 | reference all names in scope at the beginning of the try block and @NAME@ |
---|
[1c1c180] | 603 | introduced in the handler clause. If the condition is true, then the handler |
---|
[1830a86] | 604 | matches. Otherwise, the exception search continues as if the exception type |
---|
| 605 | did not match. |
---|
[f6106a6] | 606 | |
---|
[4aba055] | 607 | The condition matching allows finer matching by checking |
---|
[f6106a6] | 608 | more kinds of information than just the exception type. |
---|
[4706098c] | 609 | \begin{cfa} |
---|
| 610 | try { |
---|
[f6106a6] | 611 | handle1 = open( f1, ... ); |
---|
| 612 | handle2 = open( f2, ... ); |
---|
| 613 | handle3 = open( f3, ... ); |
---|
[4706098c] | 614 | ... |
---|
[de47a9d] | 615 | } catch( IOFailure * f ; fd( f ) == f1 ) { |
---|
[f6106a6] | 616 | // Only handle IO failure for f1. |
---|
| 617 | } catch( IOFailure * f ; fd( f ) == f3 ) { |
---|
| 618 | // Only handle IO failure for f3. |
---|
[4706098c] | 619 | } |
---|
[e3984a68] | 620 | // Handle a failure relating to f2 further down the stack. |
---|
[4706098c] | 621 | \end{cfa} |
---|
[4aba055] | 622 | In this example the file that experienced the IO error is used to decide |
---|
[f6106a6] | 623 | which handler should be run, if any at all. |
---|
| 624 | |
---|
| 625 | \begin{comment} |
---|
| 626 | % I know I actually haven't got rid of them yet, but I'm going to try |
---|
| 627 | % to write it as if I had and see if that makes sense: |
---|
| 628 | \section{Reraising} |
---|
| 629 | \label{s:Reraising} |
---|
[4706098c] | 630 | Within the handler block or functions called from the handler block, it is |
---|
| 631 | possible to reraise the most recently caught exception with @throw@ or |
---|
[1830a86] | 632 | @throwResume@, respectively. |
---|
[4706098c] | 633 | \begin{cfa} |
---|
[29c9b23] | 634 | try { |
---|
| 635 | ... |
---|
| 636 | } catch( ... ) { |
---|
[1830a86] | 637 | ... throw; |
---|
[4706098c] | 638 | } catchResume( ... ) { |
---|
[1830a86] | 639 | ... throwResume; |
---|
[4706098c] | 640 | } |
---|
| 641 | \end{cfa} |
---|
| 642 | The only difference between a raise and a reraise is that reraise does not |
---|
| 643 | create a new exception; instead it continues using the current exception, \ie |
---|
| 644 | no allocation and copy. However the default handler is still set to the one |
---|
| 645 | visible at the raise point, and hence, for termination could refer to data that |
---|
| 646 | is part of an unwound stack frame. To prevent this problem, a new default |
---|
| 647 | handler is generated that does a program-level abort. |
---|
[f6106a6] | 648 | \end{comment} |
---|
| 649 | |
---|
| 650 | \subsection{Comparison with Reraising} |
---|
[e3984a68] | 651 | In languages without conditional catch, that is no ability to match an |
---|
| 652 | exception based on something other than its type, it can be mimicked |
---|
| 653 | by matching all exceptions of the right type, checking any additional |
---|
| 654 | conditions inside the handler and re-raising the exception if it does not |
---|
| 655 | match those. |
---|
| 656 | |
---|
| 657 | Here is a minimal example comparing both patterns, using @throw;@ |
---|
| 658 | (no argument) to start a re-raise. |
---|
| 659 | \begin{center} |
---|
| 660 | \begin{tabular}{l r} |
---|
[f6106a6] | 661 | \begin{cfa} |
---|
| 662 | try { |
---|
[f42a6b8] | 663 | do_work_may_throw(); |
---|
[e3984a68] | 664 | } catch(exception_t * exc ; |
---|
| 665 | can_handle(exc)) { |
---|
[f42a6b8] | 666 | handle(exc); |
---|
[f6106a6] | 667 | } |
---|
| 668 | |
---|
[e3984a68] | 669 | |
---|
| 670 | |
---|
| 671 | \end{cfa} |
---|
| 672 | & |
---|
[f6106a6] | 673 | \begin{cfa} |
---|
| 674 | try { |
---|
[f42a6b8] | 675 | do_work_may_throw(); |
---|
[e3984a68] | 676 | } catch(exception_t * exc) { |
---|
[f42a6b8] | 677 | if (can_handle(exc)) { |
---|
| 678 | handle(exc); |
---|
| 679 | } else { |
---|
| 680 | throw; |
---|
| 681 | } |
---|
[f6106a6] | 682 | } |
---|
| 683 | \end{cfa} |
---|
[e3984a68] | 684 | \end{tabular} |
---|
| 685 | \end{center} |
---|
| 686 | At first glance catch-and-reraise may appear to just be a quality of life |
---|
| 687 | feature, but there are some significant differences between the two |
---|
| 688 | stratagies. |
---|
| 689 | |
---|
| 690 | A simple difference that is more important for \CFA than many other languages |
---|
| 691 | is that the raise site changes, with a re-raise but does not with a |
---|
| 692 | conditional catch. |
---|
| 693 | This is important in \CFA because control returns to the raise site to run |
---|
| 694 | the per-site default handler. Because of this only a conditional catch can |
---|
| 695 | allow the original raise to continue. |
---|
| 696 | |
---|
| 697 | The more complex issue comes from the difference in how conditional |
---|
| 698 | catches and re-raises handle multiple handlers attached to a single try |
---|
| 699 | statement. A conditional catch will continue checking later handlers while |
---|
| 700 | a re-raise will skip them. |
---|
| 701 | If the different handlers could handle some of the same exceptions, |
---|
| 702 | translating a try statement that uses one to use the other can quickly |
---|
| 703 | become non-trivial: |
---|
| 704 | |
---|
| 705 | \noindent |
---|
| 706 | Original, with conditional catch: |
---|
| 707 | \begin{cfa} |
---|
| 708 | ... |
---|
| 709 | } catch (an_exception * e ; check_a(e)) { |
---|
| 710 | handle_a(e); |
---|
| 711 | } catch (exception_t * e ; check_b(e)) { |
---|
| 712 | handle_b(e); |
---|
| 713 | } |
---|
| 714 | \end{cfa} |
---|
| 715 | Translated, with re-raise: |
---|
| 716 | \begin{cfa} |
---|
| 717 | ... |
---|
| 718 | } catch (exception_t * e) { |
---|
| 719 | an_exception * an_e = (virtual an_exception *)e; |
---|
| 720 | if (an_e && check_a(an_e)) { |
---|
| 721 | handle_a(an_e); |
---|
| 722 | } else if (check_b(e)) { |
---|
| 723 | handle_b(e); |
---|
| 724 | } else { |
---|
| 725 | throw; |
---|
| 726 | } |
---|
| 727 | } |
---|
| 728 | \end{cfa} |
---|
| 729 | (There is a simpler solution if @handle_a@ never raises exceptions, |
---|
| 730 | using nested try statements.) |
---|
| 731 | |
---|
| 732 | % } catch (an_exception * e ; check_a(e)) { |
---|
| 733 | % handle_a(e); |
---|
| 734 | % } catch (exception_t * e ; !(virtual an_exception *)e && check_b(e)) { |
---|
| 735 | % handle_b(e); |
---|
| 736 | % } |
---|
[4aba055] | 737 | % |
---|
[e3984a68] | 738 | % } catch (an_exception * e) |
---|
| 739 | % if (check_a(e)) { |
---|
| 740 | % handle_a(e); |
---|
| 741 | % } else throw; |
---|
| 742 | % } catch (exception_t * e) |
---|
| 743 | % if (check_b(e)) { |
---|
| 744 | % handle_b(e); |
---|
| 745 | % } else throw; |
---|
| 746 | % } |
---|
| 747 | In similar simple examples translating from re-raise to conditional catch |
---|
| 748 | takes less code but it does not have a general trivial solution either. |
---|
| 749 | |
---|
| 750 | So, given that the two patterns do not trivially translate into each other, |
---|
| 751 | it becomes a matter of which on should be encouraged and made the default. |
---|
| 752 | From the premise that if a handler that could handle an exception then it |
---|
| 753 | should, it follows that checking as many handlers as possible is preferred. |
---|
| 754 | So conditional catch and checking later handlers is a good default. |
---|
[4a36b344] | 755 | |
---|
| 756 | \section{Finally Clauses} |
---|
[f6106a6] | 757 | \label{s:FinallyClauses} |
---|
[de47a9d] | 758 | Finally clauses are used to preform unconditional clean-up when leaving a |
---|
[f6106a6] | 759 | scope and are placed at the end of a try statement after any handler clauses: |
---|
[4706098c] | 760 | \begin{cfa} |
---|
[4a36b344] | 761 | try { |
---|
[4706098c] | 762 | GUARDED_BLOCK |
---|
[29c9b23] | 763 | } ... // any number or kind of handler clauses |
---|
| 764 | ... finally { |
---|
[4706098c] | 765 | FINALLY_BLOCK |
---|
[4a36b344] | 766 | } |
---|
[4706098c] | 767 | \end{cfa} |
---|
[29c9b23] | 768 | The @FINALLY_BLOCK@ is executed when the try statement is removed from the |
---|
[1830a86] | 769 | stack, including when the @GUARDED_BLOCK@ finishes, any termination handler |
---|
[f42a6b8] | 770 | finishes or during an unwind. |
---|
[29c9b23] | 771 | The only time the block is not executed is if the program is exited before |
---|
[1830a86] | 772 | the stack is unwound. |
---|
[4706098c] | 773 | |
---|
| 774 | Execution of the finally block should always finish, meaning control runs off |
---|
[f6106a6] | 775 | the end of the block. This requirement ensures control always continues as if |
---|
| 776 | the finally clause is not present, \ie finally is for cleanup not changing |
---|
| 777 | control flow. |
---|
| 778 | Because of this requirement, local control flow out of the finally block |
---|
[1c1c180] | 779 | is forbidden. The compiler precludes any @break@, @continue@, @fallthru@ or |
---|
[4706098c] | 780 | @return@ that causes control to leave the finally block. Other ways to leave |
---|
| 781 | the finally block, such as a long jump or termination are much harder to check, |
---|
[f6106a6] | 782 | and at best requiring additional run-time overhead, and so are only |
---|
[1830a86] | 783 | discouraged. |
---|
| 784 | |
---|
[f6106a6] | 785 | Not all languages with unwinding have finally clauses. Notably \Cpp does |
---|
[e3984a68] | 786 | without it as destructors, and the RAII design pattern, serve a similar role. |
---|
| 787 | Although destructors and finally clauses can be used for the same cases, |
---|
[4aba055] | 788 | they have their own strengths, similar to top-level function and lambda |
---|
| 789 | functions with closures. |
---|
[e3984a68] | 790 | Destructors take more work to create, but if there is clean-up code |
---|
| 791 | that needs to be run every time a type is used, they are much easier |
---|
| 792 | to set-up for each use. % It's automatic. |
---|
[4aba055] | 793 | On the other hand finally clauses capture the local context, so is easy to |
---|
| 794 | use when the clean-up is not dependent on the type of a variable or requires |
---|
| 795 | information from multiple variables. |
---|
[4a36b344] | 796 | |
---|
| 797 | \section{Cancellation} |
---|
[f6106a6] | 798 | \label{s:Cancellation} |
---|
[de47a9d] | 799 | Cancellation is a stack-level abort, which can be thought of as as an |
---|
[f6106a6] | 800 | uncatchable termination. It unwinds the entire current stack, and if |
---|
[de47a9d] | 801 | possible forwards the cancellation exception to a different stack. |
---|
[4706098c] | 802 | |
---|
[29c9b23] | 803 | Cancellation is not an exception operation like termination or resumption. |
---|
[4706098c] | 804 | There is no special statement for starting a cancellation; instead the standard |
---|
[1c1c180] | 805 | library function @cancel_stack@ is called passing an exception. Unlike a |
---|
[f6106a6] | 806 | raise, this exception is not used in matching only to pass information about |
---|
[4706098c] | 807 | the cause of the cancellation. |
---|
[e3984a68] | 808 | Finally, as no handler is provided, there is no default handler. |
---|
[4706098c] | 809 | |
---|
[f6106a6] | 810 | After @cancel_stack@ is called the exception is copied into the EHM's memory |
---|
[4aba055] | 811 | and the current stack is unwound. |
---|
| 812 | The behaviour after that depends on the kind of stack being cancelled. |
---|
[a6c45c6] | 813 | |
---|
| 814 | \paragraph{Main Stack} |
---|
[4706098c] | 815 | The main stack is the one used by the program main at the start of execution, |
---|
[f6106a6] | 816 | and is the only stack in a sequential program. |
---|
| 817 | After the main stack is unwound there is a program-level abort. |
---|
| 818 | |
---|
[e3984a68] | 819 | The first reason for this behaviour is for sequential programs where there |
---|
| 820 | is only one stack, and hence to stack to pass information to. |
---|
| 821 | Second, even in concurrent programs, the main stack has no dependency |
---|
| 822 | on another stack and no reliable way to find another living stack. |
---|
| 823 | Finally, keeping the same behaviour in both sequential and concurrent |
---|
| 824 | programs is simple and easy to understand. |
---|
[4706098c] | 825 | |
---|
[a6c45c6] | 826 | \paragraph{Thread Stack} |
---|
[f6106a6] | 827 | A thread stack is created for a \CFA @thread@ object or object that satisfies |
---|
| 828 | the @is_thread@ trait. |
---|
[4aba055] | 829 | After a thread stack is unwound, the exception is stored until another |
---|
[f6106a6] | 830 | thread attempts to join with it. Then the exception @ThreadCancelled@, |
---|
| 831 | which stores a reference to the thread and to the exception passed to the |
---|
[4aba055] | 832 | cancellation, is reported from the join to the joining thread. |
---|
[f6106a6] | 833 | There is one difference between an explicit join (with the @join@ function) |
---|
| 834 | and an implicit join (from a destructor call). The explicit join takes the |
---|
| 835 | default handler (@defaultResumptionHandler@) from its calling context while |
---|
[4aba055] | 836 | the implicit join provides its own; which does a program abort if the |
---|
[f6106a6] | 837 | @ThreadCancelled@ exception cannot be handled. |
---|
| 838 | |
---|
[4aba055] | 839 | The communication and synchronization are done here because threads only have |
---|
| 840 | two structural points (not dependent on user-code) where |
---|
| 841 | communication/synchronization happens: start and join. |
---|
[f6106a6] | 842 | Since a thread must be running to perform a cancellation (and cannot be |
---|
| 843 | cancelled from another stack), the cancellation must be after start and |
---|
[4aba055] | 844 | before the join, so join is used. |
---|
[f6106a6] | 845 | |
---|
| 846 | % TODO: Find somewhere to discuss unwind collisions. |
---|
| 847 | The difference between the explicit and implicit join is for safety and |
---|
| 848 | debugging. It helps prevent unwinding collisions by avoiding throwing from |
---|
| 849 | a destructor and prevents cascading the error across multiple threads if |
---|
| 850 | the user is not equipped to deal with it. |
---|
[33e1c91] | 851 | It is always possible to add an explicit join if that is the desired behaviour. |
---|
| 852 | |
---|
| 853 | With explicit join and a default handler that triggers a cancellation, it is |
---|
[e3984a68] | 854 | possible to cascade an error across any number of threads, |
---|
| 855 | alternating between the resumption (possibly termination) and cancellation, |
---|
| 856 | cleaning up each |
---|
[33e1c91] | 857 | in turn, until the error is handled or the main thread is reached. |
---|
[f6106a6] | 858 | |
---|
[a6c45c6] | 859 | \paragraph{Coroutine Stack} |
---|
[f6106a6] | 860 | A coroutine stack is created for a @coroutine@ object or object that |
---|
| 861 | satisfies the @is_coroutine@ trait. |
---|
[4aba055] | 862 | After a coroutine stack is unwound, control returns to the @resume@ function |
---|
| 863 | that most recently resumed it. @resume@ reports a |
---|
[21f2e92] | 864 | @CoroutineCancelled@ exception, which contains a references to the cancelled |
---|
[f6106a6] | 865 | coroutine and the exception used to cancel it. |
---|
[4aba055] | 866 | The @resume@ function also takes the \defaultResumptionHandler{} from the |
---|
[21f2e92] | 867 | caller's context and passes it to the internal report. |
---|
[f6106a6] | 868 | |
---|
[e3984a68] | 869 | A coroutine only knows of two other coroutines, |
---|
| 870 | its starter and its last resumer. |
---|
[4aba055] | 871 | The starter has a much more distant connection, while the last resumer just |
---|
[f6106a6] | 872 | (in terms of coroutine state) called resume on this coroutine, so the message |
---|
| 873 | is passed to the latter. |
---|
[33e1c91] | 874 | |
---|
| 875 | With a default handler that triggers a cancellation, it is possible to |
---|
[e3984a68] | 876 | cascade an error across any number of coroutines, |
---|
| 877 | alternating between the resumption (possibly termination) and cancellation, |
---|
| 878 | cleaning up each in turn, |
---|
[33e1c91] | 879 | until the error is handled or a thread stack is reached. |
---|