[[Property:title|Handling Syntax and Validity Errors]]
[[Property:weight|-3]]
[[Property:uuid|c2be8123-b793-f8ce-e082-d4fdacc6bbe6]]
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 [[ECMA Standard 367|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.
[[Image:es gt development window syntax error 01|Purposely injected syntax error]]
The error shows up in the [[Error List Tool|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 [[ECMA Standard 367|ISO/ECMA Eiffel Standard]].
==A validity error==
A validity error is a violation of one of the validity constraints given in [[ECMA Standard 367|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.
[[Image:es gt development window validity error 01|inv: INVALID uncommented]]
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:
[[Image:es gt development window validity error 02|Validity error]]
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:
[[Image:es gt development window validity error 03|Validity error exposed]]
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 ([[Image:error-cursor]]). Like other picked objects, when it is not over a droppable target, the pebble will be crossed in red ([[Image:error-cursor-disabled]]). The place to drop is the Explanation hole ([[Image:error-info]]) in the Error List toolbar:
[[Image:es gt error list tool pnd validity error|Dropping a validity error pebble]]
When you drop the pebble, you'll see the Compilation Error Wizard appear:
[[Image:es gt compilation error wizard 01]]
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 [[ECMA Standard 367|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.