2. Error Handling
• It is an important feature of any compiler.
• A good compiler should be able to detect and report
errors.
• It should be able to modify input, when it finds an
error in lexical analysis phase.
• A more sophisticated compiler should be able to
correct the errors, by making guess of user
intentions.
3. Error Handling
• The most important feature of error handler is
correct and more centric error message.
• It should following properties:-
– Reporting errors in original source program, rather than
intermediate or final code.
– Error message shouldn’t be complicated.
– Error message shouldn’t be duplicated.
– Error message should localize the problem.
4. Sources of Error
• Algorithmic Errors:-
– The algorithm used to meet the design may be
inadequate or incorrect.
• Coding Errors:-
– The programmer may introduce syntax or logical errors
in implementing the algorithms.
5. Sources of Error
• Lexical Phase:-
– wrongly formed identifiers (or tokens).
– Some character used which is undefined in PL.
– Addition of an extra character.
– Removal of a character that should be present.
– Replacement of a character with an incorrect characters.
– Transposition of 2 characters.
6. Sources of Error
• Lexical Phase:-
– Best way to handle a lexical error is to find the closest
character sequence that does match a pattern (takes
long time & unpractical)
– Another way is to feed lexical analyzer – a list of
legitimate token available to the error recovery routines.
– Or generate an error.
7. Sources of Error
• Syntactic:-
– Comma instead of a semi-colon.
– Misspelled keywords, operators.
– Two expressions not connected by operator.
– Null expression between parenthesis
– Unbalanced parenthesis
– Handle is absent
• Usually, panic mode or phrase-level recovery is
used.
8. Sources of Error
• Semantic:
– Declaration and scope errors like use of undeclared
or multi-declared identifiers, type mismatch, etc.
– In case of undeclared name, make an entry in the
Symbol table & its attributes.
– Set a flag in ST that it was done due to an error
rather than declaration.
9. Sources of Error
• Logical:
– Syntax is correct, but wrong logic applied to programmer.
– Most difficult to recover.
– Hard to detect by compiler.
10. Goals of Error Handler
• Detect errors quickly and produce meaningful
diagnostic.
• Detect subsequent errors after an error correction.
• It shouldn’t slow down compilation.
11. Goals of Error Handler
Program submitted to a compiler often have errors of
various kinds:-
• So, good compiler should be able to detect as many
errors as possible in various ways.
• Even in the presence of errors ,the compiler should
scan the program and try to compile all of it.(error
recovery).
12. Goals of Error Handler
• When the scanner or parser finds an error and
cannot proceed ?
• Then, the compiler must modify the input so that the
correct portions of the program can be pieced
together and successfully processed in the syntax
analysis phase.
13. CORRECTING COMPILER
• These compilers does the job of error recovery not
only from the compiler point of view but also from
the programmers point of view.
• Ex:PL/C
• But, error recovery should not lead to misleading or
spurious error messages elsewhere (error
propagation).
14. Run-Time Errors
• Indication of run time errors is another neglected
area in compiler design.
• Because, code generated to monitor these
violations increases the target program size, which
leads to slow execution.
• So these checks are included as “debugging
options”.
15. Error Recovery Strategies
There are four common error-recovery strategies that
can be implemented in the parser to deal with errors
in the code:-
• Panic mode recovery
• Phrase-level recovery
• Error productions
• Global correction
16. Error Recovery Strategies
Panic Mode Recovery:-
• Once an error is found, the parser intends to find
designated set of synchronizing tokens (delimiters,
semicolon or } ) by discarding input symbols one at
a time.
• When parser finds an error in the statement, it
ignores the rest of the statement by not processing
the input.
17. Error Recovery Strategies
Panic Mode Recovery:-
• This is the easiest way of error-recovery.
• It prevents the parser from developing infinite loops.
• Ex: a=b + c // no semi-colon
• d=e + f ;
• The compiler will discard all subsequent tokens till a
semi-colon is encountered.
18. Error Recovery Strategies
Phrase-level Recovery:-
• Perform local correction on the remaining input i.e.
localize the problem and then do error recovery.
• It’s a fast way for error recovery.
• Ex: A typical local correction is to replace a comma
by a semicolon.
• Ex: Delete an extraneous semicolon and Insert a
missing semicolon.
19. Error Recovery Strategies
Error Productions:-
• Add rules to grammar that describe the erroneous
syntax.
• It may resolve many, but not all potential errors.
• Good idea about common errors is found & their
appropriate solution is stored.
• These productions detect the anticipated errors
during parsing.
20. Error Recovery Strategies
Error Productions:-
• Ex: E→ +E | -E | *E | /E
• Here, the last two are error situations.
• Now, we change the grammar as:
E→ +E | -E | *A | /A
A→ E
• Hence, once it encounters *A, it sends an error
message asking the user if he is sure he wants to
use a unary “*”.
21. Error Recovery Strategies
Global Correction:-
• Compiler to make as few changes as possible in
processing an incorrect input string.
• Given an incorrect input string x and grammar g,
algorithms will find a parse tree for a related string y,
such that the number of insertions, deletions, and
changes of tokens required to transform x into y is
as small as possible.
22. Error Recovery Strategies
Global Correction:-
• It does the global analysis to find the errors.
• Expensive method & not practically used.
• Costly in terms of time & space.