<p>The alternative to showing multiple parse errors at once is to display and handle each error individually as they are encountered during the parsing process, which I would presume is simpler to implement. Although I would presume that showing multiple parse errors at once is simpler for debugging for the users. What are some of the other pros and cons of showing multiple parse errors at once?</p>

<language-design><error-handling>
What are the pros and cons of showing multiple parse errors at once?
CC BY-SA 4.0
2023-07-03T15:53:54.830Z
Related: [What ways are there to determine if cascading compile errors are dependent or independent?](https://langdev.stackexchange.com/q/833/156)
pppery
<p>Multiple errors at once...</p>
<h3>Con: creates false positive noise</h3>
<p>An obvious con is the case where subsequent errors are caused by earlier ones.</p>
<p>For example a missing semi-colon or close bracket causes the next statement to be treated as part of the previous one. That statement is a variable which is now no longer defined. Assume there is no clever semi-colon insertion here.</p>
<pre><code>foo(x         // error: missing close bracket
y = 2;
bar();
z = 2 * y;    // error: y not defined
</code></pre>
<h3>Con: verbosity</h3>
<p>Another con is the verbosity. If you report all the errors you can you may scare people off.
The most important errors may be lost in the noise.</p>
<h3>Con: wastes time</h3>
<p>You may have to wait for the compiler to finish spouting errors before you can run it again in some environments. For a big project this can be time consuming.</p>
<h3>Pro: delay the need to recompile</h3>
<p>You can tackle multiple errors at once before having to hit recompile (for an AOT compiled language).</p>
<h3>Pro: Errors can be loaded into an IDE or another analysis tool.</h3>
<p>Uses can determine importance of errors.</p>
<p>If multiple errors are loaded into the IDE users can click to jump to the ones they think are important.</p>
<h2>Mitigations...</h2>
<h3>Rank errors</h3>
<p>A clever compiler could try to rank errors by significance to reduce noise.</p>
<h3>Guess fix and continue</h3>
<p>It can try to guess a fix to your code and see if that removes subsequent warnings (insert the expected symbol - semi-colon or close bracket).
It might of course fail by being &quot;too clever by half&quot;.</p>
<h3>Re-synchronise</h3>
<p>Compilers can also re-synchronise on good code occurring later on.</p>
<pre><code>compiler: okay I don't know what's wrong with this function but 
          maybe I can compile the next one - which I think starts here...
</code></pre>
<h3>Re-compile in the background</h3>
<p>If you have background process (E.g. using a language server) you could re-parse code in the background.</p>

CC BY-SA 4.0
2023-07-03T14:43:56.080Z
2023-07-03T14:43:56.080Z
Bruce Adams
# What are the pros and cons of showing multiple parse errors at once?
Posted by: username_0 on 2023-07-03
The alternative to showing multiple parse errors at once is to display and handle each error individually as they are encountered during the parsing process, which I would presume is simpler to implement. Although I would presume that showing multiple parse errors at once is simpler for debugging for the users. What are some of the other pros and cons of showing multiple parse errors at once?
**Tags:** language-design error-handling
> **Comments:**
> **username_1**: Related: [What ways are there to determine if cascading compile errors are dependent or independent?](https://langdev.stackexchange.com/q/833/156)  
---
## 1 answers
### Answer by username_2 on 2023-07-03. Score: 7 | Accepted answer
Multiple errors at once...
Con: creates false positive noise
An obvious con is the case where subsequent errors are caused by earlier ones.
For example a missing semi-colon or close bracket causes the next statement to be treated as part of the previous one. That statement is a variable which is now no longer defined. Assume there is no clever semi-colon insertion here.
foo(x         // error: missing close bracket
y = 2;
bar();
z = 2 * y;    // error: y not defined

Con: verbosity
Another con is the verbosity. If you report all the errors you can you may scare people off.
The most important errors may be lost in the noise.
Con: wastes time
You may have to wait for the compiler to finish spouting errors before you can run it again in some environments. For a big project this can be time consuming.
Pro: delay the need to recompile
You can tackle multiple errors at once before having to hit recompile (for an AOT compiled language).
Pro: Errors can be loaded into an IDE or another analysis tool.
Uses can determine importance of errors.
If multiple errors are loaded into the IDE users can click to jump to the ones they think are important.
Mitigations...
Rank errors
A clever compiler could try to rank errors by significance to reduce noise.
Guess fix and continue
It can try to guess a fix to your code and see if that removes subsequent warnings (insert the expected symbol - semi-colon or close bracket).
It might of course fail by being "too clever by half".
Re-synchronise
Compilers can also re-synchronise on good code occurring later on.
compiler: okay I don't know what's wrong with this function but 
          maybe I can compile the next one - which I think starts here...

Re-compile in the background
If you have background process (E.g. using a language server) you could re-parse code in the background.
---
