- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/theses/andrew_beach_MMath/features.tex
ra6c45c6 r6a8208cb 20 20 \subparagraph{Raise} 21 21 The raise is the starting point for exception handling. It marks the beginning 22 of exception handling by raisingan excepion, which passes it to22 of exception handling by \newterm{raising} an excepion, which passes it to 23 23 the EHM. 24 24 … … 101 101 between different sub-hierarchies. 102 102 This design is used in \CFA even though it is not a object-orientated 103 language ; so different tools are usedto create the hierarchy.103 language using different tools to create the hierarchy. 104 104 105 105 % Could I cite the rational for the Python IO exception rework? … … 123 123 \section{Virtuals} 124 124 Virtual types and casts are not part of \CFA's EHM nor are they required for 125 any EHM. 126 However the \CFA uses a hierarchy built with the virtual system as the basis 127 for exceptions and exception matching. 128 129 The virtual system would have ideally been part of \CFA before the work 130 on exception handling began, but unfortunately it was not. 131 Because of this only the features and framework needed for the EHM were 132 designed and implemented. Other features were considered to ensure that 133 the structure could accomidate other desirable features but they were not 134 implemented. 135 The rest of this section will only discuss the finalized portion of the 136 virtual system. 125 any EHM. But \CFA uses a hierarchial system of exceptions and this feature 126 is leveraged to create that. 127 128 % Maybe talk about why the virtual system is so minimal. 129 % Created for but not a part of the exception system. 137 130 138 131 The virtual system supports multiple ``trees" of types. Each tree is … … 182 175 While much of the virtual infrastructure is created, it is currently only used 183 176 internally for exception handling. The only user-level feature is the virtual 184 cast, which is the same as the \Cpp \ codeCpp{dynamic_cast}.177 cast, which is the same as the \Cpp \lstinline[language=C++]|dynamic_cast|. 185 178 \label{p:VirtualCast} 186 179 \begin{cfa} … … 204 197 \begin{cfa} 205 198 trait is_exception(exceptT &, virtualT &) { 206 // Numerous imaginary assertions.199 virtualT const & get_exception_vtable(exceptT *); 207 200 }; 208 201 \end{cfa} 209 202 The trait is defined over two types, the exception type and the virtual table 210 type. Each exception type should have but a single virtual table type. 211 Now there are no actual assertions in this trait because the trait system 212 actually can't express them (adding such assertions would be part of 213 completing the virtual system). The imaginary assertions would probably come 214 from a trait defined by the virtual system, and state that the exception type 215 is a virtual type, is a decendent of @exception_t@ (the base exception type) 216 and note its virtual table type. 203 type. This should be one-to-one: each exception type has only one virtual 204 table type and vice versa. The only assertion in the trait is 205 @get_exception_vtable@, which takes a pointer of the exception type and 206 returns a reference to the virtual table type instance. 207 208 % TODO: This section, and all references to get_exception_vtable, are 209 % out-of-data. Perhaps wait until the update is finished before rewriting it. 210 The function @get_exception_vtable@ is actually a constant function. 211 Regardless of the value passed in (including the null pointer) it should 212 return a reference to the virtual table instance for that type. 213 The reason it is a function instead of a constant is that it make type 214 annotations easier to write as you can use the exception type instead of the 215 virtual table type; which usually has a mangled name. 216 % Also \CFA's trait system handles functions better than constants and doing 217 % it this way reduce the amount of boiler plate we need. 217 218 218 219 % I did have a note about how it is the programmer's responsibility to make … … 234 235 Both traits ensure a pair of types are an exception type and its virtual table 235 236 and defines one of the two default handlers. The default handlers are used 236 as fallbacks and are discussed in detail in \ vref{s:ExceptionHandling}.237 as fallbacks and are discussed in detail in \VRef{s:ExceptionHandling}. 237 238 238 239 However, all three of these traits can be tricky to use directly. … … 350 351 for particular exception type. 351 352 The global default termination handler performs a cancellation 352 (see \vref{s:Cancellation})on the current stack with the copied exception.353 \see{\VRef{s:Cancellation}} on the current stack with the copied exception. 353 354 354 355 \subsection{Resumption} … … 425 426 426 427 \subsubsection{Resumption Marking} 427 \label{s:ResumptionMarking}428 428 A key difference between resumption and termination is that resumption does 429 429 not unwind the stack. A side effect that is that when a handler is matched … … 472 472 The symmetry between resumption termination is why this pattern was picked. 473 473 Other patterns, such as marking just the handlers that caught, also work but 474 lack the symmetry means there are morerules to remember.474 lack the symmetry means there are less rules to remember. 475 475 476 476 \section{Conditional Catch} … … 557 557 \end{cfa} 558 558 If there are further handlers after this handler only the first version will 559 check them. If multiple handlers on a single try block that could handle the560 sameexception the translations get more complex but they are equivilantly559 check them. If multiple handlers on a single try block could handle the same 560 exception the translations get more complex but they are equivilantly 561 561 powerful. 562 562 … … 633 633 and the current stack is 634 634 unwound. After that it depends one which stack is being cancelled. 635 636 \ paragraph{Main Stack}635 \begin{description} 636 \item[Main Stack:] 637 637 The main stack is the one used by the program main at the start of execution, 638 638 and is the only stack in a sequential program. … … 645 645 to, so it would have be explicitly managed. 646 646 647 \ paragraph{Thread Stack}647 \item[Thread Stack:] 648 648 A thread stack is created for a \CFA @thread@ object or object that satisfies 649 649 the @is_thread@ trait. … … 671 671 Also you can always add an explicit join if that is the desired behaviour. 672 672 673 \ paragraph{Coroutine Stack}673 \item[Coroutine Stack:] 674 674 A coroutine stack is created for a @coroutine@ object or object that 675 675 satisfies the @is_coroutine@ trait. … … 685 685 (in terms of coroutine state) called resume on this coroutine, so the message 686 686 is passed to the latter. 687 \end{description}
Note: See TracChangeset
for help on using the changeset viewer.