Error Detection & Recovery

3,526 views 23 slides Jul 16, 2021
Slide 1
Slide 1 of 23
Slide 1
1
Slide 2
2
Slide 3
3
Slide 4
4
Slide 5
5
Slide 6
6
Slide 7
7
Slide 8
8
Slide 9
9
Slide 10
10
Slide 11
11
Slide 12
12
Slide 13
13
Slide 14
14
Slide 15
15
Slide 16
16
Slide 17
17
Slide 18
18
Slide 19
19
Slide 20
20
Slide 21
21
Slide 22
22
Slide 23
23

About This Presentation

This ppt is about error handling in the compiler design. It also states the error recovering strategies.


Slide Content

Error Detection & Recovery

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.

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 fina l code. Error message shouldn’t be complicated. Error message shouldn’t be duplicated. Error message should localize the problem .

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 .

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.

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.

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.

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.

Sources of Error Logical : Syntax is correct, but wrong logic applied to programmer. Most difficult to recover. Hard to detect by compiler.

Goals of Error Handler Detect errors quickly and produce meaningful diagnostic. Detect subsequent errors after an error correction. It shouldn’t slow down compilation.

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 ).

Goals of Error Handler W hen 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.

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).

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” .

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

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.

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.

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.

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.

Error Recovery Strategies Error Productions :- Ex: E→ +E | -E | *E | / E Here, the last two are error situations. N ow , we change the grammar as: E→ +E | -E | *A | /A A→ E H ence , once it encounters *A, it sends an error message asking the user if he is sure he wants to use a unary “*”.

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.

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.