source: doc/theses/andrew_beach_MMath/features.tex @ 1dfe6a6

Last change on this file since 1dfe6a6 was 4a36b344, checked in by Andrew Beach <ajbeach@…>, 12 months ago

Andrew MMath: Finally got the first draft of the features done.

  • Property mode set to 100644
File size: 13.6 KB
3This chapter covers the design and user interface of the \CFA exception
4handling mechanism.
6\section{Virtual Casts}
8Virtual casts and virtual types are not truly part of the exception system but
9they did not exist in \CFA and are useful in exceptions. So a minimal version
10of they virtual system was designed and implemented.
12Virtual types are organizied in simple hierarchies. Each virtual type may have
13a parent and can have any number of children. A type's descendants are its
14children and its children's descendants. A type may not be its own descendant.
16Each virtual type has an associated virtual table type. A virtual table is a
17structure that has fields for all the virtual members of a type. A virtual
18type has all the virtual members of its parent and can add more. It may also
19update the values of the virtual members.
21Except for virtual casts, this is only used internally in the exception
22system. There is no general purpose interface for the other features. A
23a virtual cast has the following syntax:
29This has the same precidence as a traditional C-cast and can be used in the
30same places. This will convert the result of EXPRESSION to the type TYPE. Both
31the type of EXPRESSION and TYPE must be pointers to virtual types.
33The cast is checked and will either return the original value or null, based
34on the result of the check. The check is does the object pointed at have a
35type that is a descendant of the target type. If it is the result is the
36pointer, otherwise the result is null.
39% Leaving until later, hopefully it can talk about actual syntax instead
40% of my many strange macros. Syntax aside I will also have to talk about the
41% features all exceptions support.
45Termination exception throws are likely the most framilar kind, as they are
46used in several popular programming languages. A termination will throw an
47exception, search the stack for a handler, unwind the stack to where the
48handler is defined, execute the handler and then continue execution after
49the handler. They are used when execution cannot continue here.
51Termination has two pieces of syntax it uses. The first is the throw:
56The expression must evaluate to a reference to a termination exception. A
57termination exception is any exception with a
58\codeCFA{void defaultTerminationHandler(T &);} (the default handler) defined
59on it. The handler is taken from the call sight with \CFA's trait system and
60passed into the exception system along with the exception itself.
62The exception passed into the system is then copied into managed memory.
63This is to ensure it remains in scope during unwinding. It is the user's
64responsibility to make sure the original exception is freed when it goes out
65of scope. Being allocated on the stack is sufficient for this.
67Then the exception system will search the stack starting from the throw and
68proceding towards the base of the stack, from callee to caller. As it goes
69it will check any termination handlers it finds:
72try {
74} catch (EXCEPTION_TYPE * NAME) {
79This shows a try statement with a single termination handler. The statements
80in TRY\_BLOCK will be executed when control reaches this statement. While
81those statements are being executed if a termination exception is thrown and
82it is not handled by a try statement further up the stack the EHM will check
83all of the terminations handlers attached to the try block, top to bottom.
85At each handler the EHM will check to see if the thrown exception is a
86descendant of EXCEPTION\_TYPE. If it is the pointer to the exception is
87bound to NAME and the statements in HANDLER are executed. If control reaches
88the end of the handler then it exits the block, the exception is freed and
89control continues after the try statement.
91The default handler is only used if no handler for the exception is found
92after the entire stack is searched. When that happens the default handler
93is called with a reference to the exception as its only argument. If the
94handler returns control continues from after the throw statement.
96\paragraph{Conditional Catches}
98Catch clauses may also be written as:
102This has the same behaviour as a regular catch clause except that if the
103exception matches the given type the condition is also run. If the result is
104true only then is this considered a matching handler. If the result is false
105then the handler does not match and the search continues with the next clause
106in the try block.
108The condition considers all names in scope at the beginning of the try block
109to be in scope along with the name introduce in the catch clause itself.
113You can also rethrow the most recent termination exception with
114\codeCFA{throw;}. % This is terrible and you should never do it.
115This can be done in a handler or any function that could be called from a
118This will start another termination throw reusing the exception, meaning it
119does not copy the exception or allocated any more memory for it. However the
120default handler is still at the original through and could refer to data that
121was on the unwound section of the stack. So instead a new default handler that
122does a program level abort is used.
126Resumption exceptions are less popular then termination but in many
127regards are simpler and easier to understand. A resumption throws an exception,
128searches for a handler on the stack, executes that handler on top of the stack
129and then continues execution from the throw. These are used when a problem
130needs to be fixed before execution continues.
132A resumption is thrown with a throw resume statement:
134throwResume EXPRESSION;
136The result of EXPRESSION must be a resumption exception type. A resumption
137exception type is any type that satifies the assertion
138\codeCFA{void defaultResumptionHandler(T &);} (the default handler). When the
139statement is executed the expression is evaluated and the result is thrown.
141Handlers are declared using clauses in try statements:
143try {
144    TRY_BLOCK
145} catchResume (EXCEPTION_TYPE * NAME) {
146    HANDLER
149This is a simple example with the try block and a single resumption handler.
150Multiple resumption handlers can be put in a try statement and they can be
151mixed with termination handlers.
153When a resumption begins it will start searching the stack starting from
154the throw statement and working its way to the callers. In each try statement
155handlers will be tried top to bottom. Each handler is checked by seeing if
156the thrown exception is a descendant of EXCEPTION\_TYPE. If not the search
157continues. Otherwise NAME is bound to a pointer to the exception and the
158HANDLER statements are executed. After they are finished executing control
159continues from the throw statement.
161If no approprate handler is found then the default handler is called. The
162throw statement acts as a regular function call passing the exception to
163the default handler and after the handler finishes executing control continues
164from the throw statement.
166The exception system also tracks the position of a search on the stack. If
167another resumption exception is thrown while a resumption handler is running
168it will first check handlers pushed to the stack by the handler and any
169functions it called, then it will continue from the try statement that the
170handler is a part of; except for the default handler where it continues from
171the throw the default handler was passed to.
173This makes the search pattern for resumption reflect the one for termination,
174which is what most users expect.
176% This might need a diagram. But it is an important part of the justifaction
177% of the design of the traversal order.
178It also avoids the recursive resumption problem. If the entire stack is
179searched loops of resumption can form. Consider a handler that handles an
180exception of type A by resuming an exception of type B and on the same stack,
181later in the search path, is a second handler that handles B by resuming A.
183Assuming no other handlers on the stack handle A or B then in either traversal
184system an A resumed from the top of the stack will be handled by the first
185handler. A B resumed from the top or from the first handler it will be handled
186by the second hander. The only difference is when A is thrown from the second
187handler. The entire stack search will call the first handler again, creating a
188loop. Starting from the position in the stack though will break this loop.
190\paragraph{Conditional Catches}
192Resumption supports conditional catch clauses like termination does. They
193use the same syntax except the keyword is changed:
198It also has the same behaviour, after the exception type has been matched
199with the EXCEPTION\_TYPE the CONDITION is evaluated with NAME in scope. If
200the result is true then the hander is run, otherwise the search continues
201just as if there had been a type mismatch.
205You may also re-throw resumptions with a \codeCFA{throwResume;} statement.
206This can only be done from inside of a \codeCFA{catchResume} block.
208Outside of any side effects of any code already run in the handler this will
209have the same effect as if the exception had not been caught in the first
212\section{Finally Clauses}
214A \codeCFA{finally} clause may be placed at the end of a try statement after
215all the handler clauses. In the simply case, with no handlers, it looks like
219try {
220    TRY_BLOCK
221} finally {
226Any number of termination handlers and resumption handlers may proceed the
227finally clause.
229The FINAL\_STATEMENTS, the finally block, are executed whenever the try
230statement is removed from the stack. This includes: the TRY\_BLOCK finishes
231executing, a termination exception finishes executing and the stack unwinds.
233Execution of the finally block should finish by letting control run off
234the end of the block. This is because after the finally block is complete
235control will continue to where ever it would if the finally clause was not
238Because of this local control flow out of the finally block is forbidden.
239The compiler rejects uses of \codeCFA{break}, \codeCFA{continue},
240\codeCFA{fallthru} and \codeCFA{return} that would cause control to leave
241the finally block. Other ways to leave the finally block - such as a long
242jump or termination - are much harder to check, at best requiring additional
243runtime overhead, and so are merely discouraged.
247Cancellation can be thought of as a stack-level abort or as an uncatchable
248termination. It unwinds the entirety of the current exception and if possible
249passes an exception to a different stack as a message.
251There is no special statement for starting a cancellation, instead you call
252the standard libary function \codeCFA{cancel\_stack} which takes an exception.
253Unlike in a throw this exception is not used in control flow but is just there
254to pass information about why the cancellation happened.
256The handler is decided entirely by which stack is being cancelled. There are
257three handlers that apply to three different groups of stacks:
259\item Main Stack:
260The main stack is the one on which the program main is called at the beginning
261of your program. It is also the only stack you have without the libcfathreads.
263Because of this there is no other stack ``above" (or possibly at all) for main
264to notify when a cancellation occurs. So after the stack is unwound we do a
265program level abort.
267\item Thread Stack:
268Thread stacks are those created \codeCFA{thread} or otherwise satify the
269\codeCFA{is\_thread} trait.
271Threads only have two structural points of communication that must happen,
272start and join. As the thread must be running to preform a cancellation it
273will be after start and before join, so join is one cancellation uses.
275After the stack is unwound the thread will halt as if had completed normally
276and wait for another thread to join with it. The other thread, when it joins,
277checks for a cancellation. If so it will throw the resumption exception
280There is a difference here in how explicate joins (with the \codeCFA{join}
281function) and implicate joins (from a destructor call). Explicate joins will
282take the default handler (\codeCFA{defaultResumptionHandler}) from the context
283and use like a regular through does if the exception is not caught. The
284implicate join does a program abort instead.
286This is for safety. One of the big problems in exceptions is you cannot handle
287two terminations or cancellations on the same stack as either can destroy the
288context required for the other. This can happen with join but as the
289destructors will always be run when the stack is being unwound and one
290termination/cancellation is already active. Also since they are implicite they
291are easier to forget about.
293\item Coroutine Stack:
294Coroutine stacks are those created with \codeCFA{coroutine} or otherwise
295satify the \codeCFA{is\_coroutine} trait.
297A coroutine knows of two other coroutines, its starter and its last resumer.
298The last resumer is ``closer" so that is the one notified.
300After the stack is unwound control goes to the last resumer.
301Resume will resume throw a \codeCFA{CoroutineCancelled} exception, which is
302polymorphic over the coroutine type and has a pointer to the coroutine being
303cancelled and the cancelling exception. The resume function also has an
304assertion that the \codeCFA{defaultResumptionHandler} for the exception. So it
305will use the default handler like a regular throw.
Note: See TracBrowser for help on using the repository browser.