Yeah, it’s definitely a bad idea to press on beyond the point where you can reasonably recover, and actually better to err on the side of fewer diagnostics and

Yeah, it’s definitely a bad idea to press on beyond the point where you can reasonably recover, and actually better to err on the side of fewer diagnostics and less information per message if it means the messages aren’t misleading. For example, if a compiler says “Expected semicolon before open bracket”…you should be able to insert a semicolon there! In my experience, that’s what a beginner programmer or someone unfamiliar with the language is going to try. If that’s not possible, the compiler is probably leaking implementation details of the parser, and should say something else. The most important thing is that the source location points to the actual code where something is wrong so the programmer can examine it. The message is secondary—make it actionable if possible, otherwise just avoid making it actively harmful. But it also really depends on the language how well you can do recovery. Most languages in wide use are not designed to handle this, in both syntax & semantics. Again, even if you don’t want to go for full error-recovery, it’s still a good thing to support in a compiler pipeline, because it makes it easier to produce good error messages if the compiler accepts a superset of the actual language—recognising common mistakes in order to offer fixes, for example.