A compiler uses phrase-level error recovery to insert a missing semicolon and then emits 30 additional error messages, most of which are spurious. What most likely happened?
AThe program genuinely contains 31 independent syntax errors
BThe inserted semicolon repaired the syntax but left the parser in a state inconsistent with the programmer's intent, causing cascading errors downstream
CPhrase-level recovery is inherently broken and should never be used in production compilers
DThe synchronization point chosen was correct, but the grammar is ambiguous
Phrase-level recovery attempts to patch the input minimally — inserting or deleting tokens to allow parsing to continue from the exact point of failure. The risk is that the repair reflects the compiler's guess about what the programmer meant, not what the programmer actually intended. If the guess is wrong, the parser enters a state that doesn't match the remaining input, and subsequent correct code looks wrong from the parser's perspective, triggering a cascade of false errors. Panic mode avoids this by skipping to a reliable synchronization point at the cost of missing errors in the skipped region.
Question 2 Multiple Choice
When a type checker encounters an expression that could not be successfully type-checked due to an earlier error, it assigns the expression a special 'error type' compatible with all other types. Why?
ATo immediately halt compilation and prevent code generation from producing incorrect output
BTo allow type checking to continue past the damaged expression without generating spurious 'type mismatch' errors for every subsequent use of that expression
CBecause the error type is the most precise type inference possible given incomplete information
DTo mark the expression for deletion during a subsequent cleanup pass
The goal of error recovery throughout the compiler is maximum signal, minimum noise: report each genuine mistake exactly once. If a type checker leaves an erroneous expression without a type, every downstream operation involving that expression will generate its own 'type mismatch' error — all of them false positives caused by the original problem. Assigning an 'error type' (also called 'poison' or 'bottom') that is compatible with any type makes those downstream checks succeed silently, so the programmer sees one real error rather than dozens of consequential ones. The same principle explains why a failed declaration still records the variable as existing-but-erroneous.
Question 3 True / False
Panic-mode error recovery attempts to fix the syntax error by inserting or deleting minimal tokens, then resumes parsing from the exact point of failure.
TTrue
FFalse
Answer: False
That describes phrase-level recovery, not panic mode. Panic-mode recovery takes a cruder approach: upon encountering an unexpected token, it simply discards tokens — skipping them entirely — until it finds a synchronization point (a semicolon, closing brace, or keyword like 'class' or 'function') that reliably marks the start of a new construct. It then resumes parsing from that synchronizing token. Panic mode makes no attempt to repair the syntax; it just escapes the damaged region. This is why it rarely produces cascading errors but may miss genuine errors in the skipped tokens.
Question 4 True / False
Production compilers continue parsing after encountering a syntax error specifically so that developers can see and fix multiple errors in a single compilation pass.
TTrue
FFalse
Answer: True
This is the direct motivation for error recovery. A compiler that stops at the first error forces the developer to fix one mistake, recompile, find the next error, fix it, recompile, and repeat — potentially many times for a file with ten errors. Error recovery lets the parser push through damaged regions and report as many genuine errors as possible in one pass. The tradeoff is complexity: recovery strategies must be carefully designed to minimize cascading false positives while maximizing the genuine errors found.
Question 5 Short Answer
Describe the core tension between panic-mode error recovery and phrase-level recovery. What does each strategy optimize for, and what does each sacrifice?
Think about your answer, then reveal below.
Model answer: Panic mode optimizes for robustness: by skipping to a known-good synchronization point, it avoids cascading false errors because the parser resumes in a reliably correct state. The cost is that errors in the skipped tokens go unreported. Phrase-level recovery optimizes for precision: by patching the input minimally (inserting/deleting tokens), it attempts to recover from the exact point of failure and catch more errors. The cost is the risk of cascading false errors when the repair doesn't match programmer intent, burying real problems in noise.
Understanding this tradeoff is the key practical insight of compiler error recovery. The art of a good production compiler is knowing when to use each strategy — often switching to panic mode after phrase-level repairs fail to stabilize the parse, or after the error count exceeds a threshold. The overarching design principle is always the same: report genuine errors clearly while suppressing noise, so that the programmer's attention is directed toward real problems.