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