It works best in an IDE, or in my case in Emacs where I can jump to each error in turn. On the command line or in an interactive mode (REPL, notebook, &c.) I usually just want one error at a time. I’ve had fairly good luck with this in C# in Visual Studio or Xamarin Studio with Roslyn, although I don’t actually use .NET much—even though I worked on Mono for a few years, hah.
It also really depends on the grammar of the language how well you can do recovery. Ideally a language should be designed from the beginning to support it. Simple example: if a language allows nested function definitions with the same notation as top-level definitions, then you can’t reliably insert a missing closing bracket for a definition, because you can’t assume that the next one is a new top-level; it could be nested. (Although of course you can use heuristics like indentation to get around this.)
Anyway, the point of successful recovery is that the diagnostics later in the file are not spurious. And if the compiler supports recoverable parsing, you can still have a mode where it just bails out after the first error if that’s what you prefer.
> Anyway, the point of successful recovery is that the diagnostics later in the file are not spurious.
True if you only consider superficial syntax things. False in the real world, where compilers also check whether identifiers are declared, and with what type. If you have an error (syntax or semantic) and decide to press on, in general your symbol tables will be in a messed-up state, and you will generate spurious type or "undeclared identifier" errors. Also, in the real world, the compilers I have experience with do not only continue if they can be 100% sure that it makes sense, but they invariably continue further because they try to be "smart".
The IDE point is a semi-valid point since it doesn't scroll to the bottom-most, most useless errors like a terminal does. But I'm still not convinced that it adds value. That it enables situations where it's better to fix the second error before the first.
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.
It also really depends on the grammar of the language how well you can do recovery. Ideally a language should be designed from the beginning to support it. Simple example: if a language allows nested function definitions with the same notation as top-level definitions, then you can’t reliably insert a missing closing bracket for a definition, because you can’t assume that the next one is a new top-level; it could be nested. (Although of course you can use heuristics like indentation to get around this.)
Anyway, the point of successful recovery is that the diagnostics later in the file are not spurious. And if the compiler supports recoverable parsing, you can still have a mode where it just bails out after the first error if that’s what you prefer.