1 | \chapter{Exception Features} |
---|
2 | |
---|
3 | This chapter covers the design and user interface of the \CFA |
---|
4 | exception-handling mechanism (EHM). % or exception system. |
---|
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. |
---|
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. |
---|
16 | These are the two parts a programmer writes and so |
---|
17 | are the only two pieces of the EHM that have language syntax. |
---|
18 | |
---|
19 | \subparagraph{Raise} |
---|
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. |
---|
23 | |
---|
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. |
---|
27 | |
---|
28 | \subparagraph{Handle} |
---|
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". |
---|
38 | |
---|
39 | \paragraph{Propagation} |
---|
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 |
---|
49 | and repeating down the stack. |
---|
50 | |
---|
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 |
---|
56 | a possible handler. |
---|
57 | |
---|
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 |
---|
62 | the most expensive step in handling an exception. The latter tends to be the |
---|
63 | case when stack unwinding is involved. |
---|
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 |
---|
68 | installed differently. |
---|
69 | |
---|
70 | \subparagraph{Hierarchy} |
---|
71 | Some EHM (\CFA, Java) organize exceptions in a hierarchical structure. |
---|
72 | This strategy is borrowed from object-orientated languages where the |
---|
73 | exception hierarchy is a natural extension of the object hierarchy. |
---|
74 | |
---|
75 | Consider the following hierarchy of exceptions: |
---|
76 | \begin{center} |
---|
77 | \input{exceptionHierarchy} |
---|
78 | \end{center} |
---|
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 |
---|
81 | (here \lstinline[language=C++]{exception}) acts as a catch-all, leaf types catch single types |
---|
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, |
---|
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 |
---|
88 | non-object-orientated language. |
---|
89 | |
---|
90 | % Could I cite the rational for the Python IO exception rework? |
---|
91 | |
---|
92 | \paragraph{Completion} |
---|
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. |
---|
99 | |
---|
100 | \paragraph{Communication} |
---|
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. |
---|
105 | |
---|
106 | \section{Virtuals} |
---|
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. |
---|
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 |
---|
114 | one parent -- except for the root type with zero parents -- and any |
---|
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. |
---|
120 | % A type's descendents are its children and its children's descendents. |
---|
121 | |
---|
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. |
---|
127 | |
---|
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 |
---|
131 | as a hidden field. |
---|
132 | |
---|
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 |
---|
135 | single set of behaviours in each type, universally across the entire program, |
---|
136 | and indeed all programs that use that type definition. In this sense, the |
---|
137 | types are ``closed" and cannot be altered. |
---|
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 |
---|
149 | sets the virtual members for that object. The virtual members can be accessed |
---|
150 | through the object. |
---|
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 |
---|
154 | cast, which is the same as the \Cpp \lstinline[language=C++]|dynamic_cast|. |
---|
155 | \label{p:VirtualCast} |
---|
156 | \begin{cfa} |
---|
157 | (virtual TYPE)EXPRESSION |
---|
158 | \end{cfa} |
---|
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. |
---|
162 | The cast dynamically checks if the @EXPRESSION@ type is the same or a subtype |
---|
163 | of @TYPE@, and if true, returns a pointer to the |
---|
164 | @EXPRESSION@ object, otherwise it returns @0p@ (null pointer). |
---|
165 | |
---|
166 | \section{Exception} |
---|
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 | |
---|
171 | Exceptions are defined by the trait system; there are a series of traits, and |
---|
172 | if a type satisfies them, then it can be used as an exception. The following |
---|
173 | is the base trait all exceptions need to match. |
---|
174 | \begin{cfa} |
---|
175 | trait is_exception(exceptT &, virtualT &) { |
---|
176 | virtualT const & get_exception_vtable(exceptT *); |
---|
177 | }; |
---|
178 | \end{cfa} |
---|
179 | The trait is defined over two types, the exception type and the virtual table |
---|
180 | type. These type should have a one-to-one relationship: each exception type has only one virtual |
---|
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 |
---|
183 | returns a reference to the virtual-table type-instance. |
---|
184 | |
---|
185 | The function @get_exception_vtable@ is actually a constant function. |
---|
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. |
---|
191 | % Also \CFA's trait system handles functions better than constants and doing |
---|
192 | % it this way reduce the amount of boiler plate we need. |
---|
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 |
---|
196 | % similar system I know of (except Ada's I guess) so I took it out. |
---|
197 | |
---|
198 | There are two more exception traits defined as follows: |
---|
199 | \begin{cfa} |
---|
200 | trait is_termination_exception( |
---|
201 | exceptT &, virtualT & | is_exception(exceptT, virtualT)) { |
---|
202 | void defaultTerminationHandler(exceptT &); |
---|
203 | }; |
---|
204 | |
---|
205 | trait is_resumption_exception( |
---|
206 | exceptT &, virtualT & | is_exception(exceptT, virtualT)) { |
---|
207 | void defaultResumptionHandler(exceptT &); |
---|
208 | }; |
---|
209 | \end{cfa} |
---|
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: |
---|
219 | @IS_EXCEPTION@, @IS_TERMINATION_EXCEPTION@ and @IS_RESUMPTION_EXCEPTION@. |
---|
220 | |
---|
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. |
---|
223 | The second (optional) argument is a parenthesized list of polymorphic |
---|
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 |
---|
227 | match so these macros can be used without losing flexibility. |
---|
228 | |
---|
229 | For example consider a function that is polymorphic over types that have a |
---|
230 | defined arithmetic exception: |
---|
231 | \begin{cfa} |
---|
232 | forall(Num | @IS_EXCEPTION(Arithmetic, Num)@) |
---|
233 | void some_math_function(Num & left, Num & right); |
---|
234 | \end{cfa} |
---|
235 | where the function may raise exception @Arithmetic@ or any of its decedents. |
---|
236 | |
---|
237 | \section{Exception Handling} |
---|
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} |
---|
256 | |
---|
257 | \subsection{Termination} |
---|
258 | \label{s:Termination} |
---|
259 | Termination handling is familiar and used in most programming |
---|
260 | languages with exception handling. |
---|
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. |
---|
265 | |
---|
266 | % (usually) Control can continue in the current function but then a different |
---|
267 | % control flow construct should be used. |
---|
268 | |
---|
269 | A termination raise is started with the @throw@ statement: |
---|
270 | \begin{cfa} |
---|
271 | throw EXPRESSION; |
---|
272 | \end{cfa} |
---|
273 | The expression must return a reference to a termination exception, where the |
---|
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, |
---|
287 | from callee to caller. |
---|
288 | At each stack frame, a check is made for termination handlers defined by the |
---|
289 | @catch@ clauses of a @try@ statement. |
---|
290 | \begin{cfa} |
---|
291 | try { |
---|
292 | GUARDED_BLOCK |
---|
293 | } catch (EXCEPTION_TYPE$\(_1\)$ [* NAME$\(_1\)$]) { |
---|
294 | HANDLER_BLOCK$\(_1\)$ |
---|
295 | } catch (EXCEPTION_TYPE$\(_2\)$ [* NAME$\(_2\)$]) { |
---|
296 | HANDLER_BLOCK$\(_2\)$ |
---|
297 | } |
---|
298 | \end{cfa} |
---|
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 |
---|
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 |
---|
312 | freed and control continues after the @try@ statement. |
---|
313 | |
---|
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. |
---|
319 | |
---|
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. |
---|
326 | |
---|
327 | \subsection{Resumption} |
---|
328 | \label{s:Resumption} |
---|
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, |
---|
335 | then the function can continue. |
---|
336 | |
---|
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 | |
---|
343 | A resumption raise is started with the @throwResume@ statement: |
---|
344 | \begin{cfa} |
---|
345 | throwResume EXPRESSION; |
---|
346 | \end{cfa} |
---|
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 |
---|
351 | the exception system while handling the exception. |
---|
352 | |
---|
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. |
---|
355 | |
---|
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, |
---|
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. |
---|
361 | \begin{cfa} |
---|
362 | try { |
---|
363 | GUARDED_BLOCK |
---|
364 | } catchResume (EXCEPTION_TYPE$\(_1\)$ [* NAME$\(_1\)$]) { |
---|
365 | HANDLER_BLOCK$\(_1\)$ |
---|
366 | } catchResume (EXCEPTION_TYPE$\(_2\)$ [* NAME$\(_2\)$]) { |
---|
367 | HANDLER_BLOCK$\(_2\)$ |
---|
368 | } |
---|
369 | \end{cfa} |
---|
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. |
---|
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 | |
---|
401 | \subsection{Resumption Marking} |
---|
402 | A key difference between resumption and termination is that resumption does |
---|
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 |
---|
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} |
---|
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 |
---|
422 | same handler leading to an infinite loop. |
---|
423 | |
---|
424 | While this situation is trivial and easy to avoid, much more complex cycles |
---|
425 | can form with multiple handlers and different exception types. |
---|
426 | |
---|
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. |
---|
432 | |
---|
433 | % This might need a diagram. But it is an important part of the justification |
---|
434 | % of the design of the traversal order. |
---|
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 |
---|
456 | skips everything from the original throw to the original catch because that |
---|
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. |
---|
461 | |
---|
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. |
---|
465 | |
---|
466 | \section{Conditional Catch} |
---|
467 | Both termination and resumption handler-clauses can be given an additional |
---|
468 | condition to further control which exceptions is handled: |
---|
469 | \begin{cfa} |
---|
470 | catch (EXCEPTION_TYPE [* NAME] @; CONDITION@) |
---|
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 |
---|
474 | reference all names in the scope of the try block and @NAME@ |
---|
475 | introduced in the handler clause. If the condition is true, then the handler |
---|
476 | matches. Otherwise, the exception search continues as if the exception type |
---|
477 | did not match. |
---|
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. |
---|
494 | \begin{cfa} |
---|
495 | try { |
---|
496 | f1 = open( ... ); |
---|
497 | f2 = open( ... ); |
---|
498 | ... |
---|
499 | } catch( CreateFailure * f ) { |
---|
500 | if ( @fd( f ) == f1@ ) ... else // reraise |
---|
501 | } catch( OpenFailure * f ) { |
---|
502 | if ( @fd( f ) == f2@ ) ... else // reraise |
---|
503 | } |
---|
504 | \end{cfa} |
---|
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 |
---|
515 | have rethrows/reraises instead.} |
---|
516 | |
---|
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 |
---|
519 | @throwResume@, respectively. |
---|
520 | \begin{cfa} |
---|
521 | try { |
---|
522 | ... |
---|
523 | } catch( ... ) { |
---|
524 | ... throw; |
---|
525 | } catchResume( ... ) { |
---|
526 | ... throwResume; |
---|
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. |
---|
535 | \PAB{I don't see how this is different from the normal throw/throwResume.} |
---|
536 | |
---|
537 | \section{Finally Clauses} |
---|
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: |
---|
540 | \begin{cfa} |
---|
541 | try { |
---|
542 | GUARDED_BLOCK |
---|
543 | } ... // any number or kind of handler clauses |
---|
544 | ... finally { |
---|
545 | FINALLY_BLOCK |
---|
546 | } |
---|
547 | \end{cfa} |
---|
548 | The @FINALLY_BLOCK@ is executed when the try statement is removed from the |
---|
549 | stack, including when the @GUARDED_BLOCK@ finishes, any termination handler |
---|
550 | finishes, or during an unwind. |
---|
551 | The only time the block is not executed is if the program is exited before |
---|
552 | the stack is unwound. |
---|
553 | |
---|
554 | Execution of the finally block should always finish, meaning control runs off |
---|
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 |
---|
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 |
---|
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, |
---|
561 | and at best require additional run-time overhead, and so are |
---|
562 | discouraged. |
---|
563 | |
---|
564 | Not all languages with exceptions have finally clauses. Notably \Cpp does |
---|
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 |
---|
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 |
---|
569 | finally clauses are good for one-off situations and can easily include local information. |
---|
570 | |
---|
571 | \section{Cancellation} |
---|
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. |
---|
576 | |
---|
577 | Cancellation is not an exception operation like termination or resumption. |
---|
578 | There is no special statement for starting a cancellation; instead the standard |
---|
579 | library function @cancel_stack@ is called passing an exception. Unlike a |
---|
580 | throw, this exception is not used in matching only to pass information about |
---|
581 | the cause of the cancellation. |
---|
582 | (This semantics also means matching cannot fail so there is no default handler.) |
---|
583 | |
---|
584 | After @cancel_stack@ is called, the exception is copied into the EHM's |
---|
585 | memory and the current stack is |
---|
586 | unwound. After that it depends one which stack is being cancelled. |
---|
587 | \begin{description} |
---|
588 | \item[Main Stack:] |
---|
589 | The main stack is the one used by the program main at the start of execution, |
---|
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. |
---|
592 | Hence, when the main stack is cancelled there is nowhere else in the program |
---|
593 | to go. Hence, after the main stack is unwound, there is a program-level abort. |
---|
594 | |
---|
595 | \item[Thread Stack:] |
---|
596 | A thread stack is created for a \CFA @thread@ object or object that satisfies the |
---|
597 | @is_thread@ trait. A thread only has two points of communication that must |
---|
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. |
---|
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, |
---|
604 | and if present, resumes exception @ThreadCancelled@. |
---|
605 | |
---|
606 | \begin{sloppypar} |
---|
607 | There is a subtle difference between the explicit join (@join@ function) and |
---|
608 | implicit join (from a @thread@'s destructor call). The explicit join takes the default |
---|
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. |
---|
611 | \end{sloppypar} |
---|
612 | |
---|
613 | \PAB{uC++ does not have these issues, but catch(...) is not working.} |
---|
614 | \begin{lstlisting}[language=uC++] |
---|
615 | #include <iostream> |
---|
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.} |
---|
660 | This semantics is for safety. If an unwind is triggered while another unwind |
---|
661 | is underway only one of them can proceed as they both want to ``consume" the |
---|
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. |
---|
667 | |
---|
668 | \todo{Perhaps have a more general disucssion of unwind collisions before |
---|
669 | this point.} |
---|
670 | |
---|
671 | The recommended way to avoid the abort is to handle the initial resumption |
---|
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. |
---|
675 | |
---|
676 | \item[Coroutine Stack:] A coroutine stack is created for a @coroutine@ object |
---|
677 | or object that satisfies the @is_coroutine@ trait. A coroutine only knows of |
---|
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 |
---|
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} |
---|
690 | |
---|
691 | \PAB{You should have more test programs that compare \CFA EHM to uC++ EHM.} |
---|