Changeset b680198 for doc/theses/andrew_beach_MMath/features.tex
- Timestamp:
- Jun 23, 2021, 2:06:12 PM (3 years ago)
- Branches:
- ADT, ast-experimental, enum, forall-pointer-decay, jacob/cs343-translation, master, new-ast-unique-expr, pthread-emulation, qualifiedEnum
- Children:
- 68b52b0
- Parents:
- 6ba6846 (diff), 929d925 (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the(diff)
links above to see all the changes relative to each parent. - File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/theses/andrew_beach_MMath/features.tex
r6ba6846 rb680198 2 2 \label{c:features} 3 3 4 This chapter covers the design and user interface of the \CFA 5 EHM, % or exception system. 4 This chapter covers the design and user interface of the \CFA EHM 6 5 and begins with a general overview of EHMs. It is not a strict 7 6 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 7 However it does cover the most common structure and features found in them. 8 9 \section{Overview of EHMs} 10 10 % We should cover what is an exception handling mechanism and what is an 11 11 % exception before this. Probably in the introduction. Some of this could 12 12 % move there. 13 \s ection{Raise / Handle}13 \subsection{Raise / Handle} 14 14 An exception operation has two main parts: raise and handle. 15 These terms are sometimes alsoknown as throw and catch but this work uses15 These terms are sometimes known as throw and catch but this work uses 16 16 throw/catch as a particular kind of raise/handle. 17 17 These are the two parts that the user writes and may … … 24 24 25 25 Some well known examples include the @throw@ statements of \Cpp and Java and 26 the \code{Python}{raise} statement from Python. Araise may27 p erform some other work (such as memory management) but for the26 the \code{Python}{raise} statement from Python. In real systems a raise may 27 preform some other work (such as memory management) but for the 28 28 purposes of this overview that can be ignored. 29 29 … … 33 33 34 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 matches35 region of code they guard and an exception label/condition that matches 36 36 certain exceptions. 37 37 Only raises inside the guarded region and raising exceptions that match the 38 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".39 If multiple handlers could can handle an exception, 40 EHMs will define a rule to pick one, such as ``best match" or ``first found". 41 41 42 42 The @try@ statements of \Cpp, Java and Python are common examples. All three … … 44 44 region. 45 45 46 \s ection{Propagation}46 \subsection{Propagation} 47 47 After an exception is raised comes what is usually the biggest step for the 48 48 EHM: finding and setting up the handler. The propagation from raise to 49 49 handler can be broken up into three different tasks: searching for a handler, 50 matching against the handler ,and installing the handler.50 matching against the handler and installing the handler. 51 51 52 52 \paragraph{Searching} … … 55 55 thrown as it looks for handlers that have the raise site in their guarded 56 56 region. 57 Th is search includes handlers in the current function, as well as any in callers58 on the stack that have the function call in their guarded region.57 The search includes handlers in the current function, as well as any in 58 callers on the stack that have the function call in their guarded region. 59 59 60 60 \paragraph{Matching} 61 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 decideif62 label defines a condition that is used with exception and decides if 63 63 there is a match or not. 64 64 65 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 finds66 searching; a match check is preformed immediately after the search finds 67 67 a possible handler. 68 68 69 \ section{Installing}69 \paragraph{Installing} 70 70 After a handler is chosen it must be made ready to run. 71 71 The implementation can vary widely to fit with the rest of the … … 74 74 case when stack unwinding is involved. 75 75 76 If a matching handler is not guarant ied to be found, the EHM needs a76 If a matching handler is not guaranteed to be found, the EHM needs a 77 77 different course of action for the case where no handler matches. 78 78 This situation only occurs with unchecked exceptions as checked exceptions 79 79 (such as in Java) can make the guarantee. 80 This unhandled action can abort the program or install a very general handler.80 This unhandled action is usually very general, such as aborting the program. 81 81 82 82 \paragraph{Hierarchy} 83 83 A common way to organize exceptions is in a hierarchical structure. 84 This organization is often used inobject-orientated languages where the84 This pattern comes from object-orientated languages where the 85 85 exception hierarchy is a natural extension of the object hierarchy. 86 86 … … 90 90 \end{center} 91 91 92 A handler label led with any given exception can handle exceptions of that92 A handler labeled with any given exception can handle exceptions of that 93 93 type or any child type of that exception. The root of the exception hierarchy 94 94 (here \code{C}{exception}) acts as a catch-all, leaf types catch single types … … 104 104 % Could I cite the rational for the Python IO exception rework? 105 105 106 \ paragraph{Completion}107 After the handler has finished the entire exception operation has to complete106 \subsection{Completion} 107 After the handler has finished, the entire exception operation has to complete 108 108 and continue executing somewhere else. This step is usually simple, 109 109 both logically and in its implementation, as the installation of the handler … … 111 111 112 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} 113 the most common are after the handler definition (termination) 114 and after the raise (resumption). 115 116 \subsection{Communication} 116 117 For effective exception handling, additional information is often passed 117 118 from the raise to the handler and back again. 118 119 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. 120 A common communication method is putting fields into the exception instance 121 and giving the handler access to them. 122 Passing the exception by reference instead of by value can allow data to be 123 passed in both directions. 121 124 122 125 \section{Virtuals} 123 126 Virtual types and casts are not part of \CFA's EHM nor are they required for 124 127 any EHM. 125 However, one of the best ways to support an exception hierarchy is via a virtual system126 among exceptions and used for exception matching.128 However, it is one of the best ways to support an exception hierarchy 129 is via a virtual hierarchy and dispatch system. 127 130 128 131 Ideally, the virtual system would have been part of \CFA before the work 129 132 on exception handling began, but unfortunately it was not. 130 Therefore, only the features and framework needed for the EHM were133 Hence, only the features and framework needed for the EHM were 131 134 designed and implemented. Other features were considered to ensure that 132 the structure could accommodate other desirable features in the future but they were not133 implemented.134 The rest of this section discusses the implemented subset of the135 virtual -system design.135 the structure could accommodate other desirable features in the future 136 but they were not implemented. 137 The rest of this section will only discuss the implemented subset of the 138 virtual system design. 136 139 137 140 The virtual system supports multiple ``trees" of types. Each tree is … … 143 146 % A type's ancestors are its parent and its parent's ancestors. 144 147 % The root type has no ancestors. 145 % A type's de cedents are its children and its children's decedents.148 % A type's descendants are its children and its children's descendants. 146 149 147 150 Every virtual type also has a list of virtual members. Children inherit … … 150 153 of object-orientated programming, and can be of any type. 151 154 152 \PAB{I do not understand these sentences. Can you add an example? $\Rightarrow$153 155 \CFA still supports virtual methods as a special case of virtual members. 154 156 Function pointers that take a pointer to the virtual type are modified 155 157 with each level of inheritance so that refers to the new type. 156 158 This means an object can always be passed to a function in its virtual table 157 as if it were a method.} 159 as if it were a method. 160 \todo{Clarify (with an example) virtual methods.} 158 161 159 162 Each virtual type has a unique id. … … 161 164 into a virtual table type. Each virtual type has a pointer to a virtual table 162 165 as a hidden field. 163 164 \PAB{God forbid, maybe you need a UML diagram to relate these entities.} 166 \todo{Might need a diagram for virtual structure.} 165 167 166 168 Up until this point the virtual system is similar to ones found in … … 173 175 types can begin to satisfy a trait, stop satisfying a trait or satisfy the same 174 176 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 it176 is impossible to pick a single set of functions that represent the type's177 implementation across the program.177 In this sense, they are ``open" as they can change at any time. 178 This capability means it is impossible to pick a single set of functions 179 that represent the type's implementation across the program. 178 180 179 181 \CFA side-steps this issue by not having a single virtual table for each 180 182 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 183 declaration and given a name. Anywhere that name is visible, even if it is 182 184 defined locally inside a function (although that means it does not have a 183 185 static lifetime), it can be used. … … 186 188 through the object. 187 189 188 \PAB{The above explanation is very good!}189 190 190 While much of the virtual infrastructure is created, it is currently only used 191 191 internally for exception handling. The only user-level feature is the virtual 192 cast 192 cast, which is the same as the \Cpp \code{C++}{dynamic_cast}. 193 193 \label{p:VirtualCast} 194 194 \begin{cfa} 195 195 (virtual TYPE)EXPRESSION 196 196 \end{cfa} 197 which is the same as the \Cpp \code{C++}{dynamic_cast}.198 197 Note, the syntax and semantics matches a C-cast, rather than the function-like 199 198 \Cpp syntax for special casts. Both the type of @EXPRESSION@ and @TYPE@ must be … … 218 217 The trait is defined over two types, the exception type and the virtual table 219 218 type. Each exception type should have a single virtual table type. 220 There are no actual assertions in this trait because currentlythe trait system221 cannot express them (adding such assertions would be part of219 There are no actual assertions in this trait because the trait system 220 cannot express them yet (adding such assertions would be part of 222 221 completing the virtual system). The imaginary assertions would probably come 223 222 from a trait defined by the virtual system, and state that the exception type 224 is a virtual type, is a descend ent of @exception_t@ (the base exception type)223 is a virtual type, is a descendant of @exception_t@ (the base exception type) 225 224 and note its virtual table type. 226 225 … … 241 240 }; 242 241 \end{cfa} 243 Both traits ensure a pair of types are an exception type and its virtual table, 242 Both traits ensure a pair of types are an exception type, its virtual table 243 type 244 244 and defines one of the two default handlers. The default handlers are used 245 245 as fallbacks and are discussed in detail in \vref{s:ExceptionHandling}. … … 269 269 \section{Exception Handling} 270 270 \label{s:ExceptionHandling} 271 As stated, \CFA provides two kinds of exception handling: termination and resumption. 271 As stated, 272 \CFA provides two kinds of exception handling: termination and resumption. 272 273 These twin operations are the core of \CFA's exception handling mechanism. 273 This section coversthe general patterns shared by the two operations and274 then go on to cover the details ofeach individual operation.274 This section will cover the general patterns shared by the two operations and 275 then go on to cover the details each individual operation. 275 276 276 277 Both operations follow the same set of steps. 277 Both start with the user p erforming a raise on an exception.278 Both start with the user preforming a raise on an exception. 278 279 Then the exception propagates up the stack. 279 280 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,control282 continues after the raise. Note, the default handler may further change control flow rather than return.281 After that control continues at a raise-dependent location. 282 If the search fails a default handler is run and, if it returns, then control 283 continues after the raise. 283 284 284 285 This general description covers what the two kinds have in common. 285 Differences include how propagation is p erformed, where exception continues286 Differences include how propagation is preformed, where exception continues 286 287 after an exception is caught and handled and which default handler is run. 287 288 288 289 \subsection{Termination} 289 290 \label{s:Termination} 290 291 291 Termination handling is the familiar kind and used in most programming 292 292 languages with exception handling. … … 313 313 314 314 The throw copies the provided exception into managed memory to ensure 315 the exception is not destroyed whenthe stack is unwound.315 the exception is not destroyed if the stack is unwound. 316 316 It is the user's responsibility to ensure the original exception is cleaned 317 317 up whether the stack is unwound or not. Allocating it on the stack is 318 318 usually sufficient. 319 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, 320 % How to say propagation starts, its first sub-step is the search. 321 Then propagation starts with the search. \CFA uses a ``first match" rule so 322 matching is preformed with the copied exception as the search continues. 323 It starts from the throwing function and proceeds towards base of the stack, 323 324 from callee to caller. 324 325 At each stack frame, a check is made for resumption handlers defined by the … … 334 335 \end{cfa} 335 336 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 in \snake{GUARDED_BLOCK} and when those are finished, 338 the try statement finishes. 337 339 338 340 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. 341 invoked functions, all the handlers in these statements are included in the 342 search path. 343 Hence, if a termination exception is raised these handlers may be matched 344 against the exception and may handle it. 342 345 343 346 Exception matching checks the handler in each catch clause in the order 344 347 they appear, top to bottom. If the representation of the raised exception type 345 348 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 in347 @HANDLER_BLOCK@$_i$ are executed. 348 If control reaches the end of the handler, the exception is349 (if provided) is 350 bound to a pointer to the exception and the statements in @HANDLER_BLOCK@$_i$ 351 are executed. If control reaches the end of the handler, the exception is 349 352 freed and control continues after the try statement. 350 353 351 If no termination handler is found during the search ,the default handler352 (\defaultTerminationHandler) visible at the raise statement is called.353 Through \CFA's trait system , the best match at the raise sight isused.354 This function is run and is passed the copied exception. If the default355 handler returns, control continues after the throwstatement.354 If no termination handler is found during the search then the default handler 355 (\defaultTerminationHandler) visible at the raise statement is run. 356 Through \CFA's trait system the best match at the raise statement will be used. 357 This function is run and is passed the copied exception. 358 If the default handler is run control continues after the raise statement. 356 359 357 360 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 361 termination exception types. 362 Since it is so general a more specific handler can be 359 363 defined and is used for those types, effectively overriding the handler 360 364 for a particular exception type. … … 370 374 matched a closure is taken from up the stack and executed, 371 375 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.} 376 The common uses for resumption exceptions include 377 potentially repairable errors, where execution can continue in the same 378 function once the error is corrected, and 379 ignorable events, such as logging where nothing needs to happen and control 380 should always continue from the same place. 379 381 380 382 A resumption raise is started with the @throwResume@ statement: … … 382 384 throwResume EXPRESSION; 383 385 \end{cfa} 386 \todo{Decide on a final set of keywords and use them everywhere.} 384 387 It works much the same way as the termination throw. 385 388 The expression must return a reference to a resumption exception, … … 387 390 @is_resumption_exception@ at the call site. 388 391 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. 392 the exception system while handling the exception. 393 394 At run-time, no exception copy is made. 395 Resumption does not unwind the stack nor otherwise remove values from the 396 current scope, so there is no need to manage memory to keep things in scope. 397 398 The EHM then begins propagation. The search starts from the raise in the 399 resuming function and proceeds towards the base of the stack, 400 from callee to caller. 397 401 At each stack frame, a check is made for resumption handlers defined by the 398 402 @catchResume@ clauses of a @try@ statement. … … 412 416 kind of raise. 413 417 When a try statement is executed, it simply executes the statements in the 414 @GUARDED_BLOCK@ and then returns.418 @GUARDED_BLOCK@ and then finishes. 415 419 416 420 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. 421 invoked functions, all the handlers in these statements are included in the 422 search path. 423 Hence, if a resumption exception is raised these handlers may be matched 424 against the exception and may handle it. 420 425 421 426 Exception matching checks the handler in each catch clause in the order … … 427 432 the raise statement that raised the handled exception. 428 433 429 Like termination, if no resumption handler is found during the search, the default handler430 (\defaultResumptionHandler) visible at the raise statement is called. 431 It uses the best match at the 432 raise sight accordingto \CFA's overloading rules. The default handler is433 passed the exception given to the throw. When the default handler finishes434 Like termination, if no resumption handler is found during the search, 435 the default handler (\defaultResumptionHandler) visible at the raise 436 statement is called. It will use the best match at the raise sight according 437 to \CFA's overloading rules. The default handler is 438 passed the exception given to the raise. When the default handler finishes 434 439 execution continues after the raise statement. 435 440 436 There is a global \defaultResumptionHandler{} thatis polymorphic over all437 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.441 There is a global \defaultResumptionHandler{} is polymorphic over all 442 resumption exceptions and preforms a termination throw on the exception. 443 The \defaultTerminationHandler{} can be overridden by providing a new 444 function that is a better match. 440 445 441 446 \subsubsection{Resumption Marking} 442 447 \label{s:ResumptionMarking} 443 444 448 A key difference between resumption and termination is that resumption does 445 449 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 statement447 searched before it are still on the stack. The ir existence can lead to the recursive448 resumption problem.450 and run it's try block (the guarded statements) and every try statement 451 searched before it are still on the stack. There presence can lead to 452 the recursive resumption problem. 449 453 450 454 The recursive resumption problem is any situation where a resumption handler … … 459 463 \end{cfa} 460 464 When this code is executed, the guarded @throwResume@ starts a 461 search and match s the handler in the @catchResume@ clause. This462 call is placed on the top of stack above the try-block. The second throw463 search s the same try block and puts callanother instance of the464 same handler on the stack leading to aninfinite recursion.465 search and matches the handler in the @catchResume@ clause. This 466 call is placed on the stack above the try-block. The second raise then 467 searches the same try block and puts another instance of the 468 same handler on the stack leading to infinite recursion. 465 469 466 470 While this situation is trivial and easy to avoid, much more complex cycles 467 471 can form with multiple handlers and different exception types. 468 472 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, effecti fy474 skipping over themto the next try statement.473 To prevent all of these cases, a each try statement is ``marked" from the 474 time the exception search reaches it to either when the exception is being 475 handled completes the matching handler or when the search reaches the base 476 of the stack. 477 While a try statement is marked, its handlers are never matched, effectively 478 skipping over it to the next try statement. 475 479 476 480 \begin{center} … … 478 482 \end{center} 479 483 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. 484 There are other sets of marking rules that could be used, 485 for instance, marking just the handlers that caught the exception, 486 would also prevent recursive resumption. 487 However, these rules mirror what happens with termination. 488 489 The try statements that are marked are the ones that would be removed from 490 the stack if this was a termination exception, that is those on the stack 491 between the handler and the raise statement. 492 This symmetry applies to the default handler as well, as both kinds of 493 default handlers are run at the raise statement, rather than (physically 494 or logically) at the bottom of the stack. 495 % In early development having the default handler happen after 496 % unmarking was just more useful. We assume that will continue. 491 497 492 498 \section{Conditional Catch} 493 494 499 Both termination and resumption handler clauses can be given an additional 495 500 condition to further control which exceptions they handle: … … 504 509 did not match. 505 510 506 The condition matching allows finer matching to check511 The condition matching allows finer matching by checking 507 512 more kinds of information than just the exception type. 508 513 \begin{cfa} … … 519 524 // Can't handle a failure relating to f2 here. 520 525 \end{cfa} 521 In this example , the file that experianced the IO error is used to decide526 In this example the file that experienced the IO error is used to decide 522 527 which handler should be run, if any at all. 523 528 … … 548 553 549 554 \subsection{Comparison with Reraising} 550 551 555 A more popular way to allow handlers to match in more detail is to reraise 552 556 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 On the surface these two features seem interchangeable. 558 559 If @throw;@ (no argument) starts a termination reraise, 560 which is the same as a raise but reuses the last caught exception, 561 then these two statements have the same behaviour: 557 562 \begin{cfa} 558 563 try { … … 574 579 } 575 580 \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. 581 That is, they will have the same behaviour in isolation. 582 Two things can expose differences between these cases. 583 584 One is the existence of multiple handlers on a single try statement. 585 A reraise skips all later handlers on this try statement but a conditional 586 catch does not. 587 Hence, if an earlier handler contains a reraise later handlers are 588 implicitly skipped, with a conditional catch they are not. 589 Still, they are equivalently powerful, 590 both can be used two mimic the behaviour of the other, 591 as reraise can pack arbitrary code in the handler and conditional catches 592 can put arbitrary code in the predicate. 593 % I was struggling with a long explanation about some simple solutions, 594 % like repeating a condition on later handlers, and the general solution of 595 % merging everything together. I don't think it is useful though unless its 596 % for a proof. 597 % https://en.cppreference.com/w/cpp/language/throw 598 599 The question then becomes ``Which is a better default?" 600 We believe that not skipping possibly useful handlers is a better default. 601 If a handler can handle an exception it should and if the handler can not 602 handle the exception then it is probably safer to have that explicitly 603 described in the handler itself instead of implicitly described by its 604 ordering with other handlers. 605 % Or you could just alter the semantics of the throw statement. The handler 606 % index is in the exception so you could use it to know where to start 607 % searching from in the current try statement. 608 % No place for the `goto else;` metaphor. 609 610 The other issue is all of the discussion above assumes that the only 611 way to tell apart two raises is the exception being raised and the remaining 612 search path. 613 This is not true generally, the current state of the stack can matter in 614 a number of cases, even only for a stack trace after an program abort. 615 But \CFA has a much more significant need of the rest of the stack, the 616 default handlers for both termination and resumption. 617 618 % For resumption it turns out it is possible continue a raise after the 619 % exception has been caught, as if it hadn't been caught in the first place. 620 This becomes a problem combined with the stack unwinding used in termination 621 exception handling. 622 The stack is unwound before the handler is installed, and hence before any 623 reraises can run. So if a reraise happens the previous stack is gone, 624 the place on the stack where the default handler was supposed to run is gone, 625 if the default handler was a local function it may have been unwound too. 626 There is no reasonable way to restore that information, so the reraise has 627 to be considered as a new raise. 628 This is the strongest advantage conditional catches have over reraising, 629 they happen before stack unwinding and avoid this problem. 630 631 % The one possible disadvantage of conditional catch is that it runs user 632 % code during the exception search. While this is a new place that user code 633 % can be run destructors and finally clauses are already run during the stack 634 % unwinding. 635 % 636 % https://www.cplusplus.com/reference/exception/current_exception/ 637 % `exception_ptr current_exception() noexcept;` 638 % https://www.python.org/dev/peps/pep-0343/ 604 639 605 640 \section{Finally Clauses} 606 641 \label{s:FinallyClauses} 607 608 642 Finally clauses are used to preform unconditional clean-up when leaving a 609 643 scope and are placed at the end of a try statement after any handler clauses: … … 618 652 The @FINALLY_BLOCK@ is executed when the try statement is removed from the 619 653 stack, including when the @GUARDED_BLOCK@ finishes, any termination handler 620 finishes ,or during an unwind.654 finishes or during an unwind. 621 655 The only time the block is not executed is if the program is exited before 622 656 the stack is unwound. … … 634 668 635 669 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. 670 without it as descructors, and the RAII design pattern, serve a similar role. 671 Although destructors and finally clauses can be used in the same cases, 672 they have their own strengths, similar to top-level function and lambda 673 functions with closures. 674 Destructors take more work for their first use, but if there is clean-up code 675 that needs to be run every time a type is used they soon become much easier 676 to set-up. 677 On the other hand finally clauses capture the local context, so is easy to 678 use when the clean-up is not dependent on the type of a variable or requires 679 information from multiple variables. 680 % To Peter: I think these are the main points you were going for. 642 681 643 682 \section{Cancellation} … … 652 691 raise, this exception is not used in matching only to pass information about 653 692 the cause of the cancellation. 654 (This restrictionalso means matching cannot fail so there is no default handler.)693 (This also means matching cannot fail so there is no default handler.) 655 694 656 695 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. 696 and the current stack is unwound. 697 The behaviour after that depends on the kind of stack being cancelled. 660 698 661 699 \paragraph{Main Stack} … … 664 702 After the main stack is unwound there is a program-level abort. 665 703 666 There are two reasons for this semantics. The first is that it obviously had to do the abort 704 There are two reasons for these semantics. 705 The first is that it had to do this abort. 667 706 in a sequential program as there is nothing else to notify and the simplicity 668 707 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.} 708 Also, even in concurrent programs there may not currently be any other stacks 709 and even if other stacks do exist, main has no way to know where they are. 671 710 672 711 \paragraph{Thread Stack} … … 680 719 and an implicit join (from a destructor call). The explicit join takes the 681 720 default handler (@defaultResumptionHandler@) from its calling context while 682 the implicit join provides its own ,which does a program abort if the721 the implicit join provides its own; which does a program abort if the 683 722 @ThreadCancelled@ exception cannot be handled. 684 723 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.}724 The communication and synchronization are done here because threads only have 725 two structural points (not dependent on user-code) where 726 communication/synchronization happens: start and join. 688 727 Since a thread must be running to perform a cancellation (and cannot be 689 728 cancelled from another stack), the cancellation must be after start and 690 before the join, so join is use .729 before the join, so join is used. 691 730 692 731 % TODO: Find somewhere to discuss unwind collisions. … … 695 734 a destructor and prevents cascading the error across multiple threads if 696 735 the user is not equipped to deal with it. 697 Also you can always add an explicit join if that is the desired behaviour. 736 It is always possible to add an explicit join if that is the desired behaviour. 737 738 With explicit join and a default handler that triggers a cancellation, it is 739 possible to cascade an error across any number of threads, cleaning up each 740 in turn, until the error is handled or the main thread is reached. 698 741 699 742 \paragraph{Coroutine Stack} … … 701 744 satisfies the @is_coroutine@ trait. 702 745 After a coroutine stack is unwound, control returns to the @resume@ function 703 that most recently resumed it. The resumereports a704 @CoroutineCancelled@ exception, which contains references to the cancelled746 that most recently resumed it. @resume@ reports a 747 @CoroutineCancelled@ exception, which contains a references to the cancelled 705 748 coroutine and the exception used to cancel it. 706 749 The @resume@ function also takes the \defaultResumptionHandler{} from the 707 caller's context and passes it to the internal cancellation.750 caller's context and passes it to the internal report. 708 751 709 752 A coroutine knows of two other coroutines, its starter and its last resumer. … … 711 754 (in terms of coroutine state) called resume on this coroutine, so the message 712 755 is passed to the latter. 756 757 With a default handler that triggers a cancellation, it is possible to 758 cascade an error across any number of coroutines, cleaning up each in turn, 759 until the error is handled or a thread stack is reached.
Note: See TracChangeset
for help on using the changeset viewer.