Eli   Documents

General Information

 o Eli: Translator Construction Made Easy
 o Global Index
 o Frequently Asked Questions
 o Typical Eli Usage Errors

Tutorials

 o Quick Reference Card
 o Guide For new Eli Users
 o Release Notes of Eli
 o Tutorial on Name Analysis
 o Tutorial on Scope Graphs
 o Tutorial on Type Analysis
 o Typical Eli Usage Errors

Reference Manuals

 o User Interface
 o Eli products and parameters
 o LIDO Reference Manual
 o Typical Eli Usage Errors

Libraries

 o Eli library routines
 o Specification Module Library

Translation Tasks

 o Lexical analysis specification
 o Syntactic Analysis Manual
 o Computation in Trees

Tools

 o LIGA Control Language
 o Debugging Information for LIDO
 o Graphical ORder TOol

 o FunnelWeb User's Manual

 o Pattern-based Text Generator
 o Property Definition Language
 o Operator Identification Language
 o Tree Grammar Specification Language
 o Command Line Processing
 o COLA Options Reference Manual

 o Generating Unparsing Code

 o Monitoring a Processor's Execution

Administration

 o System Administration Guide

Mail Home

Library Reference

Previous Chapter Next Chapter Table of Contents


Error Reporting

#include "err.h"

int ErrorCount[ ];

ErrorInit(int ImmOut, int AGout, int ErrLimit)

message(int severity, char *text, int grammar, CoordPtr source)

lisedit(char *name; FILE *stream; int cutoff, erronly)

This module implements a set of errors of various levels of severity. Error reports are tied to particular positions in the source text coordinate system, and may be combined with the source text in a separate pass.

ErrorInit may be called in order to change the default behavior of the error module. By default, all error messages are written to stderr as they occur, however, if ErrorInit has been called with a value of 0 for ImmOut, errors will not be reported until lisedit is used. Buffering is prevented by calling fflush after each output. The error message format is illustrated by the following:

"filename", line 24:3 ERROR: boolean type required AG=124
The information shown is: the file name of the input file, the line and column in that file where the error was reported, the severity (see below) and the error message iself. The integer value following AG can be used to provide additional information when a particular report may originate from many places. This integer value is not reported if ErrorInit has been called with a value of 0 for AGout.

The format is designed so that it can be used as input to a special mechanism, such as an intelligent editor, for making the reports known to the user.

After printing to stderr, the errors are also queued for possible printing later with lisedit. lisedit prints to stdout the source line containing the error, with an arrow pointing at the corresponding column. Then the body of the error message is printed. Only messages whose severity is larger than cutoff will be printed. If erronly is nonzero, only lines with associated error reports will be printed.

The message routine is used to make an error report to the error module. Both source program and compiler errors are reported via message. Six error severities are defined by constants exported by the module:

NOTE
The message is intended to convey additional information to the user, not to report an error.
WARNING
The message reports an anomaly that may be indicative of an error.
ERROR
The message reports a definite error.
DEADLY
The message reports a violation of an assertion within the compiler.

A compiler should be able to carry on after detecting any errors less severe than deadly errors. It may be necessary to repair some internal data structures in order to guarantee their consistency, but the repairs are usually not difficult to provide; see any standard compiler construction text. Message returns normally after accepting a report of an error that is less severe than a deadly error.

Violations of compiler assertions signal programming errors within the compiler itself. Attempts to continue under such circumstances are likely to result in further corruption and eventual catastrophic failure. Message therefore does not return after accepting a report of a deadly error. Instead, it outputs any queued reports and terminates the program with exit(1).

The text argument to message points to a character string describing the error. This character string must remain unchanged until the reports are output at the end of the compilation; message does not copy it.

grammar and source serve to locate the error in both the compiler and the source text. grammar is most useful in the case of violations of compiler assertions and limits. It specifies the particular assertion or, in the case of a generated compiler, the specification rule that led to the violated assertion. source gives the source text coordinates of the construct the compiler was processing at the time the report was issued. Some errors are not associated with a particular source language construct. Reports of these errors should use NoPosition in lieu of coordinates.

At any time during the compilation, ErrorCount[severity] contains the number of reports of class severity that have been issued so far.

If an error is reported with an invalid severity code, message sets its severity to DEADLY after printing the message and its severity code on stderr.

If the number of errors at severity level ERROR is greater than 10 added to the current line number divided by 20 then compilation is aborted with a DEADLY message. When the number of lines of source is reasonably large this effectively amounts to a limit of one of these errors for every 20 lines of source code (ie. a 5% error rate). This error limit is not checked if ErrorInit has been called with a value of 0 for the argument ErrLimit.


Previous Chapter Next Chapter Table of Contents