Homework # 5 (updated 11/30)
due 2004/11/11

Exceptions for Cool

For this homework, you will add exceptions and exception handling to Cool. Any object can be thrown by using the syntax throw $o$, an expression that does not return (and has any type). An expression evaluation $e$ can be protected with handlers $h$ using the syntax: try $e$ except $h$ end. Each handler has the same syntax as a case branch. As with a case expression, the branch that most closely matches the thrown object will be executed. As is usual in languages with exception handling, the handlers are dynamically scoped. If no exception is thrown during the evaluation of $e$, the result of the protected evaluation is the same as the evaluation of $e$, otherwise if there is an exception thrown which is caught by a handler, the result of the handler is the result of the protected evaluation.

Errors that previously would terminate execution (such as dispatch on void, string index bad, etc) should now throw exceptions. (Undegraduates are not required to implement this feature.) Furthermore, an uncaught exception should be printed to stdout and the program terminates. For more information on this requirement, see below.

The throw keyword should have lower precedence than any operator except the semicolon (;) operator.

Implementing an extension

This extension mainly affects the code generation and runtime system, but also has effects on the front end. You will first need to formalize the syntax and static semantics of the extension before you implement it. Write the grammar changes and new type axioms and turn them in for a milestone by November 4th.

Normally one would also need to change the intermediate representation. This task has already been done for you, there are two new ``constructors'' for the new constructs:


constructor handle(body : Expression; cases: Cases) : Expression;
constructor raise(exception : Expression) : Expression;
The semantic analyzer and code generator will need to define routines for these new classes of nodes or there will be link errors.

Your first task will be to add the keywords to the parsers token list. The support code (which is provided to you in a library) assumes you will place them in alphabetical order in the list. If you choose some other order, there will be miscommunication between the parser and the scanner.

Obviously, the code generator will need to be changed, but (except for undergraduates) the run-time system will need to be changed as well to raise exceptions upon errors rather than aborting, and (even for undergraduates) to catch and print uncaught exceptions (and abort execution). A string should be printed. Any other object should have its class printed. If class Object had a general to_string() method, one would want to call this method, but we are not changing basic.cl at this time.

Files and Deliverables

Get copies of the required files from the homework's source directory:


grid.cs: mkdir hw5
grid.cs: cd hw5
grid.cs: make -f /afs/cs.uwm.edu/users/classes/cs754/src/homework5/makefile
NB: The 'makefile' is not capitalized.
You will notice link errors for the missing parts of the semantic analyzer and code generator. You can start by stubbing these routines out and by adding the tokens to the parser. Then you will achieve a cool compiler that can handle programs that do not use the extension. From there you can start implementing the extension. You will not need to change any .h file.

Currently, the library is only available on the grids. It is the intent to supply the source code so you can compile then library yourself.

As well as the source code (which is editable), you also receive several links to shared files:

makefile
The makefile to use to build your compiler and run it.
except.cl
An executable test case that tests exception. It includes the required output.
Please put an overview of your implementation in the provided README.

I was able to implement the entire extension (including the support code I am giving you) in about 15 hours of solid work. Here are the size of the diffs, counting both deleted and added lines (changed lines are counted twice) plus one for every deleted or added block, with changed blocks counting twice again:

cool.flex
6
cool.y
13
semant.cc
47
cgen.cc
185
trap.handler
381
Total
632
For instance cool.y has two changed lines (counts 2+2+1+1), an inserted line (counted 1+1) and a block of four inserted lines (counted 4+1) for a grand total of 6+2+5 = 13.



John Tang Boyland
2004-10-30