source: doc/theses/andrew_beach_MMath/intro.tex @ 6071efc

Last change on this file since 6071efc was 6071efc, checked in by Andrew Beach <ajbeach@…>, 3 years ago

Andrew MMath: Update the first three chapters using Colby's comments.

  • Property mode set to 100644
File size: 10.7 KB
3% The highest level overview of Cforall and EHMs. Get this done right away.
4This thesis goes over the design and implementation of the exception handling
5mechanism (EHM) of
6\CFA (pronounced sea-for-all and may be written Cforall or CFA).
7\CFA is a new programming language that extends C, that maintains
8backwards-compatibility while introducing modern programming features.
9Adding exception handling to \CFA gives it new ways to handle errors and
10make other large control-flow jumps.
12% Now take a step back and explain what exceptions are generally.
13Exception handling provides dynamic inter-function control flow.
14There are two forms of exception handling covered in this thesis:
15termination, which acts as a multi-level return,
16and resumption, which is a dynamic function call.
17Termination handling is much more common,
18to the extent that it is often seen
19This seperation is uncommon because termination exception handling is so
20much more common that it is often assumed.
21% WHY: Mention other forms of continuation and \cite{CommonLisp} here?
22A language's EHM is the combination of language syntax and run-time
23components that are used to construct, raise and handle exceptions,
24including all control flow.
26Termination exception handling allows control to return to any previous
27function on the stack directly, skipping any functions between it and the
28current function.
33Resumption exception handling seaches the stack for a handler and then calls
34it without adding or removing any other stack frames.
35\todo{Add a diagram showing control flow for resumption.}
37Although a powerful feature, exception handling tends to be complex to set up
38and expensive to use
39so they are often limited to unusual or ``exceptional" cases.
40The classic example of this is error handling, exceptions can be used to
41remove error handling logic from the main execution path and while paying
42most of the cost only when the error actually occurs.
44\section{Thesis Overview}
45This work describes the design and implementation of the \CFA EHM.
46The \CFA EHM implements all of the common exception features (or an
47equivalent) found in most other EHMs and adds some features of its own.
48The design of all the features had to be adapted to \CFA's feature set as
49some of the underlying tools used to implement and express exception handling
50in other languages are absent in \CFA.
51Still the resulting syntax resembles that of other languages:
53try {
54        ...
55        T * object = malloc(request_size);
56        if (!object) {
57                throw OutOfMemory{fixed_allocation, request_size};
58        }
59        ...
60} catch (OutOfMemory * error) {
61        ...
65% A note that yes, that was a very fast overview.
66The design and implementation of all of \CFA's EHM's features are
67described in detail throughout this thesis, whether they are a common feature
68or one unique to \CFA.
70% The current state of the project and what it contributes.
71All of these features have been implemented in \CFA, along with
72a suite of test cases as part of this project.
73The implementation techniques are generally applicable in other programming
74languages and much of the design is as well.
75Some parts of the EHM use other features unique to \CFA and these would be
76harder to replicate in other programming languages.
78% Talk about other programming languages.
79Some existing programming languages that include EHMs/exception handling
80include C++, Java and Python. All three examples focus on termination
81exceptions which unwind the stack as part of the
82Exceptions also can replace return codes and return unions.
84The contributions of this work are:
86\item Designing \CFA's exception handling mechanism, adapting designs from
87other programming languages and the creation of new features.
88\item Implementing stack unwinding and the EHM in \CFA, including updating
89the compiler and the run-time environment.
90\item Designed and implemented a prototype virtual system.
91% I think the virtual system and per-call site default handlers are the only
92% "new" features, everything else is a matter of implementation.
95\todo{I can't figure out a good lead-in to the roadmap.}
96The next section covers the existing state of exceptions.
97The existing state of \CFA is also covered in \autoref{c:existing}.
98The new features are introduced in \autoref{c:features},
99which explains their usage and design.
100That is followed by the implementation of those features in
102The performance results are examined in \autoref{c:performance}.
103Possibilities to extend this project are discussed in \autoref{c:future}.
108Exception handling is not a new concept,
109with papers on the subject dating back 70s.
111Their were popularised by \Cpp,
112which added them in its first major wave of non-object-orientated features
113in 1990.
116Java was the next popular language to use exceptions. It is also the most
117popular language with checked exceptions.
118Checked exceptions are part of the function interface they are raised from.
119This includes functions they propogate through, until a handler for that
120type of exception is found.
121This makes exception information explicit, which can improve clarity and
122safety, but can slow down programming.
123Some of these, such as dealing with high-order methods or an overly specified
124throws clause, are technical. However some of the issues are much more
125human, in that writing/updating all the exception signatures can be enough
126of a burden people will hack the system to avoid them.
127Including the ``catch-and-ignore" pattern where a catch block is used without
128anything to repair or recover from the exception.
131Resumption exceptions have been much less popular.
132Although resumption has a history as old as termination's, very few
133programming languages have implement them.
135%   CSL-79-3_Mesa_Language_Manual_Version_5.0.pdf
136Mesa is one programming languages that did and experiance with that
137languages is quoted as being one of the reasons resumptions were not
138included in the \Cpp standard.
140\todo{A comment about why we did include them when they are so unpopular
141might be approprate.}
144Functional languages, tend to use solutions like the return union, but some
145exception-like constructs still appear.
147For instance Haskell's built in error mechanism can make the result of any
148expression, including function calls. Any expression that examines an
149error value will in-turn produce an error. This continues until the main
150function produces an error or until it is handled by one of the catch
154More recently exceptions seem to be vanishing from newer programming
156Rust and Go reduce this feature to panics.
157Panicing is somewhere between a termination exception and a program abort.
158Notably in Rust a panic can trigger either, a panic may unwind the stack or
159simply kill the process.
161Go's panic is much more similar to a termination exception but there is
162only a catch-all function with \code{Go}{recover()}.
163So exceptions still are appearing, just in reduced forms.
166Exception handling's most common use cases are in error handling.
167Here are some other ways to handle errors and comparisons with exceptions.
169\item\emph{Error Codes}:
170This pattern uses an enumeration (or just a set of fixed values) to indicate
171that an error has occured and which error it was.
173There are some issues if a function wants to return an error code and another
174value. The main issue is that it can be easy to forget checking the error
175code, which can lead to an error being quitely and implicitly ignored.
176Some new languages have tools that raise warnings if the return value is
177discarded to avoid this.
178It also puts more code on the main execution path.
179\item\emph{Special Return with Global Store}:
180A function that encounters an error returns some value indicating that it
181encountered a value but store which error occured in a fixed global location.
183Perhaps the C standard @errno@ is the most famous example of this,
184where some standard library functions will return some non-value (often a
185NULL pointer) and set @errno@.
187This avoids the multiple results issue encountered with straight error codes
188but otherwise many of the same advantages and disadvantages.
189It does however introduce one other major disadvantage:
190Everything that uses that global location must agree on all possible errors.
191\item\emph{Return Union}:
192Replaces error codes with a tagged union.
193Success is one tag and the errors are another.
194It is also possible to make each possible error its own tag and carry its own
195additional information, but the two branch format is easy to make generic
196so that one type can be used everywhere in error handling code.
198This pattern is very popular in functional or semi-functional language,
199anything with primitive support for tagged unions (or algebraic data types).
200% We need listing Rust/rust to format code snipits from it.
201% Rust's \code{rust}{Result<T, E>}
203The main disadvantage is again it puts code on the main execution path.
204This is also the first technique that allows for more information about an
205error, other than one of a fix-set of ids, to be sent.
206They can be missed but some languages can force that they are checked.
207It is also implicitly forced in any languages with checked union access.
208\item\emph{Handler Functions}:
209On error the function that produced the error calls another function to
210handle it.
211The handler function can be provided locally (passed in as an argument,
212either directly as as a field of a structure/object) or globally (a global
215C++ uses this as its fallback system if exception handling fails.
216\snake{std::terminate_handler} and for a time \snake{std::unexpected_handler}
218Handler functions work a lot like resumption exceptions.
219The difference is they are more expencive to set up but cheaper to use, and
220so are more suited to more fequent errors.
221The exception being global handlers if they are rarely change as the time
222in both cases strinks towards zero.
226Because of their cost exceptions are rarely used for hot paths of execution.
227There is an element of self-fulfilling prophocy here as implementation
228techniques have been designed to make exceptions cheap to set-up at the cost
229of making them expencive to use.
230Still, use of exceptions for other tasks is more common in higher-level
231scripting languages.
232An iconic example is Python's StopIteration exception which is thrown by
233an iterator to indicate that it is exausted. Combined with Python's heavy
234use of the iterator based for-loop.
Note: See TracBrowser for help on using the repository browser.