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
to meet the design may be
• Algorithmic Errors:-
– The algorithm used
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
meaningful
• Detect errors quickly and produce
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.
