Handling Syntax and Validity Errors

So far we have tried to make sure that everything went smoothly. But in actual software development you may encounter error situations, and it is useful to know what can happen then.

Levels of language description

Let's remind ourselves first of how the language is specified. The ISO/ECMA Eiffel standard and the book Eiffel: The Language carefully distinguish between three levels of description: syntax, validity and semantics. Their roles are clearly distinct:

• Syntax defines the structure of software texts. A typical syntax rule states that an assignment starts with a Writable entity, continues with the symbol :=, and ends with an Expression. This is a purely structural specification, saying nothing for example about the types of the Writable and the Expression.
• Validity, applicable only to syntactically legal texts, defines required consistency conditions. A typical validity rule states that in an assignment the right-hand-side Expression must conform -- a property of its type, defined rigorously on the basis of inheritance -- to the left-hand-side Writable. Eiffel has about 75 validity rules; part of the language's originality is that these rules are of the "if and only if" form, not only telling you individual error cases ("this is valid only if ... ") but also reassuring you that your text will in fact be valid if it satisfies the conditions listed exhaustively.
• Semantics, applicable only to valid texts, defines the software's expected run-time behavior. A typical semantic rule states that an assignment replaces the value of its left-hand-side Writable by the value of the right-hand-side Expression at the time the assignment is executed, with precise rules on the different possible cases involving references, objects and simple values.

You may make an error at any of these levels:

• Writing = instead of := for the assignment symbol is a syntax error.
• Writing your_integer := your_real, with the types suggested by the names, is a validity error.
• Violating a precondition, causing a division by zero, are semantic errors.

Syntax and validity errors will be detected by the compilation process. For semantic errors, you will rely on contract checking and on the debugging tools described later. Let's look now at examples of the first two cases.

A syntax error

To see what happens for a syntax error, replace the keyword do by dont in the routine display of class PARENT (click the position immediately after the o and type nt.). Save the file by clicking the Save button or using CTRL-S and then compile the system.

The error shows up in the Error List tool. You can expand the entry to show the point at which the error was recognized by the compiler.

To correct the error, just bring the mouse back to its location, remove the spurious nt, and click Save again; also click Compile to make sure that the project is recompiled up-to-date.

You may wonder why the syntax error messages are not a little more verbose than just Syntax error. The reason is merely that Eiffel's syntax, being simple and regular, does not require sophisticated error messages; syntax errors usually result from trivial oversights. If you make a syntax error and the reason is not immediately clear, check the syntax summary in the Quick reference to the Eiffel programming language or the ISO/ECMA Eiffel Standard.

A validity error

A validity error is a violation of one of the validity constraints given in ISO/ECMA Eiffel Standard. Every such constraint is identified by a four-letter code of the form VXXX (the first letter is always V).

A validity error will produce a precise error message, which includes the validity code. Although short, the error message is usually sufficient to find out what the error is. If not, you can get the complete rule, straight from the book.

To see this mechanism at work, let us introduce a validity error. There is in fact one ready for you in class TESTROOT. Target a Development Window to this class; at the end of its text, just before the final end, you will find the following comment line: -- inv: INVALID;

If uncommented, this is a declaration of a feature of type INVALID. A class called INVALID indeed exists in file invalid.e of the root cluster, but it contains a validity error. To see what it is, remove the initial double-hyphen -- in the above line from class TESTROOT so that it is not a comment any more.

Click Save, then Compile. Compilation starts but after a few degrees it stops with an error message that appears in the Error List tool. Expand the entry and perhaps do some resizing to see it in its entirety:

As the error message indicates, you have (shame on you) violated the validity rule VUAR, which requires the number and types of actual arguments in a routine call to match the number and types of formal arguments declared in the routine.

One of the interesting properties of the error message is that everything in color is clickable: class name, feature name, but also the error code. This means that you can start a Pick-and-Drop on any of these elements to find out more.

For example, to see the exact context of the error, pick-and-drop the name of the affected feature, display -- appearing in green on the fifth non-blank line -- and pick-and-drop it to the Editing tool. This displays the erroneous feature:

Note on this display a special property of Pick-and-Drop when its source is a feature name appearing in a validity error message: the instruction that causes the error is highlighted.

In the error message in the Error List tool, the error code itself, VUAR, is also clickable. Assuming the message was not sufficient to understand the error, you can use it to start a Pick-and-Drop. Do this now, by picking that code and starting to move the mouse, but not dropping yet. The pebble shape for such information elements is a question mark ? enclosed in a small gold talk bubble (). Like other picked objects, when it is not over a droppable target, the pebble will be crossed in red (). The place to drop is the Explanation hole () in the Error List toolbar:

When you drop the pebble, you'll see the Compilation Error Wizard appear:

The wizard displays the complete text of the violated rule. Depending upon the particular violation, the rule will come straight from the pages of either Eiffel: The Language or the ISO/ECMA Eiffel standard. In this case, the VUAR rule definition used comes from Chapter 22, page 369 of Eiffel: The Language. An rule cited from the ISO/ECMA Eiffel standard will be state as such and will include the specific edition of the standard and the section number, for example:VEVI, ECMA-367, 2nd edition, section 8.19.17

The VUAR rule that we violated has two clauses, numbered. Since the error message showed the error code as VUAR(1), the violated clause is the first; this convention of showing the clause number in parentheses applies to all multi-clause validity constraints.

To correct the error the easiest is to go back to class TESTROOT and reinstate the comment symbol -- (two consecutive hyphens) on the erroneous line. Save and compile to continue with a valid system.