CPS710	Assignment 6
	Error Management	Due: Dec 14

Objectives

With this assignment you should become much more familiar with error management in interpreters. The learning objectives covered in this assignment are:

• 8Ba
• 8Ab

Solutions to the previous assignments, assignment 4 and 5, will not be provided. You will therefore need to complete the B level objectives of these assignments in order to work on this assignment. You do not, however, need to complete the A level objectives of assignments 4 and 5 to work on the A level objective of this assignment.

Preparation

• You will need the files in the Handouts directory.

• The class ParseAbortException.java gives you
  • A mechanism to support syntax error recovery up to a certain point using the constant MAXERRORS and two static methods ResetErrors() and IncrementErrors(). MAXERRORS describes the maximum number of attempted error recoveries. You can modify this constant to test your work, but there is no need to make any other changes to this class. Your assignment will be tested with the version that is handed out.
  • The exception ParseAbortException.TOOMANYERRORS that will be used to abort parsing when too many parsing errors have been encountered. This exception is thrown by IncrementErrors and caught by TestHL.
  • The exception ParseAbortException.EOF to halt the interpreter when EOF is reached.

• The new TestHL.java catches exceptions, prints them out, and supports recovering from them. For this assignment you will need to modify this file to handle errors in a systematic way. There are comments in the code about changes that need to be made.

• You will need to modify your HL.jjt to replace the exception currently thrown when an EOF is read by ParseAbortException.EOF to make it work with the new TestHL.java.

Assignment

These two parts are mostly independent: You can work on 8Ab (and submit it) without doing 8Ba!

8Ba: Runtime errors

When you detect a run-time error, you should throw an EvaluationException with a good error message. The error messages that you print should be as specific as possible about the location in the code and problem encountered at that point. In particular any identifier involved in the error should be named.

You will also need to modify the ASTfn_call evaluation visitor to catch and handle EvaluationExceptions in order to reset your activation stack to the global level. You may also need to modify EvaluationException.java. This file was handed out in the assignment 5 to be subclassed to handle return statements, but its main purpose is for this assignment.

The types of errors that can be detected are specified in the test files in the Tests directory. You will notice that the .expected files do not necessarily report any errors for everything, and some report errors that were thrown by JavaCC or by Java. This is how we will know what error handling you have chosen to implement: Unlike in the previous assignments where tests were passed when your program's output was the same as in the test, in this assignment we will run the tests to look for differences in three files each of which should contain at least one appropriate error message.

The test result files were generated from our assignment 5 solution running with the two new files handed out, TestHL.java and ParseAbort.java, before any error handling functionality was introduced into the code. Depending on how you've implemented assignments 4 and 5, your code may generate slightly different outputs. We are aware of that, and this is not an issue: we'll be looking for differences with good run-time error reporting.

It is likely that your error handling code will end up catching more than one error in each of the three types of errors that you choose to handle, but we are only looking for one error for each file.

8Ab: Syntax errors

1. Read the document: JavaCC: Error Handling.

2. At the end of HL.jjt, add three new error recovery productions. These productions only match the null string. They also simply print an appropriate error message and increment the ParseError counter.

   • The following two error recovery productions are intended to be incorporated into new parser productions to parse incorrect structures and print error messages when they are parsed:

         // ErrorReplace production called when token string parsed was interpreted as expected token.
         void ErrorReplace(String parsed, String expected) #void :
         
         // ErrorMissing production called when the token skipped was missing
         void ErrorMissing(String skipped) #void :
     

   • The third production goes further than the other two by consuming tokens up to a specified synchronizing token.

         // ErrorSkipto called to consume all tokens up to and including the first one of kind stoptoken
         void ErrorSkipto(int stoptoken)
     

     (Note that you can find partial code for the skipto function in JavaCC: Error Handling).

3. Now use the productions you have just defined:

   • Use ErrorReplace and ErrorMissing at least three times each in your parser to perform some shallow error recovery.

   • Use ErrorSkipto at least two times in your parser. ErrorSkipto can be used to perform shallow error recovery by incorporating it into other productions where it will simply skip tokens without affecting the production being parsed. It can also be used for deep error recovery by calling it from a catch clause of an exception.

   Don't forget to catch all exceptions in the start production to make sure that only ParseAbortExceptions escape the parser.

4. If you have implemented static scoping, you will also need to modify TestHL to reset your scope stack to the global level before each call to the parser in case parsing was aborted.

5. You will be asked to submit test files to demonstrate your error recovery strategies. This will be described in the assignment submission section.

References

• JavaCC: Error Handling describes the infrastructure provided by JavaCC to support error handling.

• JavaCC: API Routines contains a comprehensive list of all classes, methods, and variables available for use by a JavaCC user.

How to submit assignment 6

• zip up together HL.jjt, and all your source files other than the ones in the AST directory into A6B.zip.
• Submit electronically A6B.zip

  Our makefile will assume the default structure: everything in one directory except that all jjtree-generated files are in the AST subdirectory.

If you are submitting the A level learning objective: (We will test for the B level objectives to see whether you have worked on these as well.)

• Prepare a test file called testerror.hl which contains 2 statements or expressions (i.e the start production should be called twice). Each of these 2 statements (or expressions) should contain 5 of the 10 syntax errors for which you have implemented some error recovery. Altogether this should demonstrate your 10 error recoveries as described in the syntax Errors section of this assignment.
• Zip testerror.hl, HL.jjt, and all your source files other than the ones in the AST directory into A6A.zip.
• Submit electronically A6A.zip
• Describe the syntax error recovery schemes you have implemented in the syntax errors document word format or pdf format and submit in D2L assignment called "Assignment 6 - 8Ab".

  Our makefile will assume the default structure: everything in one directory except that all jjtree-generated files are in the AST subdirectory.

Assessment Process

• For 8Ba, we will run the tests in the Tests directory using the runtests program in the Handouts directory. As explained above you only have to handle one run-time error in each of three different test files and these should show up in the diff.

• For 8Ab, we will look in D2L for the table directing us to your submission. If there is one, we will run your test file testerror.hl following the directions from your D2L submission. We may fiddle with MAXERRORS along the way.