<p>In my experience as a developer, a single syntax error made in a long program can result in a long cascading list of error messages, only the first of which is directly relevant to the solution. For example, consider the following malformed C# program:</p>
<pre><code>namespace Spaaaaaace
{
    public static class RequiredTestProtocol
    {
        public static void Test()
        {
            Console.WriteLine(&quot;As part of a required test protocol, we must run this program successfully.&quot;);
        // MISSING CLOSE BRACE
    
        public static void Main(string[] args)
        {
            Test();
        }

    }

}
</code></pre>
<p>When I attempt to compile this program, I not only see the error about the missing close brace, but an additional message about how declaring <code>public</code> members within a function is not allowed, which is something I never intended to do. This additional message is solely a result of my initial error and has nothing to do with any error I made in my <code>Main</code> function.</p>
<p>On the other hand, it is entirely possible for a programmer to make multiple, independent compile-time errors within one program under circumstances in which the programmer might want to know about each instance. An example could be declaring multiple <code>for</code> loops, each of which is malformed.</p>
<p>Are there ways to differentiate each of these cases at compile time? That is, if a compiler has decided that there are multiple compile errors to report, is there a way for it to determine whether these are all independent errors or whether some or all of the later errors would be fixed by fixing an earlier error, and then reporting only the &quot;real&quot; errors?</p>

<compilers><error-handling><compiler-checks>
What ways are there to determine if cascading compile errors are dependent or independent?
<p>I don't know how this could be prevented entirely, but there are some mitigation ideas.</p>
<h2>Simply ignore successive errors</h2>
<p>When parsing fails a lot of tokens in sequence are not going to make sense leading to a lot of errors. One option is to suppress successive errors. Only if there is a &quot;gap&quot; in the errors, which would indicate the parser has found it's footing again, show more errors.</p>
<p>This way multiple errors in a file can be shown properly as long as the are sufficiently far apart.</p>
<h2>Forcibly switching context</h2>
<p>When encountering a token that doesn't make sense in the current context, for example a public function inside a method, switch the parser context to whatever place a <code>public</code> would be OK. This works well for keywords that only really make sense in one place like a class body, but if something can appear in multiple places and you guess wrong what context to switch you it could lead to even more incomprehensible errors.</p>
<h2>Using the indentation as a hint</h2>
<p>In languages with <code>{}</code> style code blocks parsers shouldn't really look at indention, but what if it did.</p>
<p>In case of a parsing error the parser can look for the nearest indent or dedent missing any kind of brace or parenthesis and insert a opening or closing brace/bracket/parenthesis there. If the code makes sense now they can give a much clearer hint about what the programmer should do while also being able to properly parse and print errors for the rest of the file.</p>
<p>This will fail if the code is not indented properly, or a indentation style is used the compiler doesn't recognize.</p>

CC BY-SA 4.0
2023-05-20T17:12:29.443Z
2023-05-20T18:55:47.957Z
2023-05-20T18:55:47.957Z
mousetail 'he-him'
CC BY-SA 4.0
2023-07-03T20:21:44.247Z
One thing about ignoring successive errors is that if you're making a language server, it won't provide highlighting for stuff after the first error.
user
<p>The problem with missing close braces is that the compiler can't know whether the errors are indeed dependent or independent. The only clues that you didn't intend to write the below code and truly made two mistakes are things that can only be understood by humans not computers:</p>
<pre><code>namespace Spaaaaaace
{
    public static class RequiredTestProtocol
    {
        public static void Test()
        {
            Console.WriteLine(&quot;As part of a required test protocol, we must run this program successfully.&quot;);
    
            static void Main(string[] args)
            {
                Test();
            }
        }
    }
}
</code></pre>
<p>It would be possible to have a hierarchy of syntax errors and only report errors high-up on the hierarchy if there are no errors lower-down on the hierarchy (with unbalanced brackets being below everything else), in which case the two for loop errors would likely be on the same level, but this can't be done in the general case.</p>

CC BY-SA 4.0
2023-05-20T17:12:58.440Z
2023-05-20T17:12:58.440Z
pppery
# What ways are there to determine if cascading compile errors are dependent or independent?
Posted by: username_0 on 2023-05-20
In my experience as a developer, a single syntax error made in a long program can result in a long cascading list of error messages, only the first of which is directly relevant to the solution. For example, consider the following malformed C# program:
namespace Spaaaaaace
{
    public static class RequiredTestProtocol
    {
        public static void Test()
        {
            Console.WriteLine("As part of a required test protocol, we must run this program successfully.");
        // MISSING CLOSE BRACE
    
        public static void Main(string[] args)
        {
            Test();
        }

    }

}

When I attempt to compile this program, I not only see the error about the missing close brace, but an additional message about how declaring public members within a function is not allowed, which is something I never intended to do. This additional message is solely a result of my initial error and has nothing to do with any error I made in my Main function.
On the other hand, it is entirely possible for a programmer to make multiple, independent compile-time errors within one program under circumstances in which the programmer might want to know about each instance. An example could be declaring multiple for loops, each of which is malformed.
Are there ways to differentiate each of these cases at compile time? That is, if a compiler has decided that there are multiple compile errors to report, is there a way for it to determine whether these are all independent errors or whether some or all of the later errors would be fixed by fixing an earlier error, and then reporting only the "real" errors?
**Tags:** compilers error-handling compiler-checks
---
## 2 answers
### Answer by username_1 on 2023-05-20. Score: 6
I don't know how this could be prevented entirely, but there are some mitigation ideas.

## Simply ignore successive errors

When parsing fails a lot of tokens in sequence are not going to make sense leading to a lot of errors. One option is to suppress successive errors. Only if there is a "gap" in the errors, which would indicate the parser has found it's footing again, show more errors.

This way multiple errors in a file can be shown properly as long as the are sufficiently far apart.

## Forcibly switching context

When encountering a token that doesn't make sense in the current context, for example a public function inside a method, switch the parser context to whatever place a `public` would be OK. This works well for keywords that only really make sense in one place like a class body, but if something can appear in multiple places and you guess wrong what context to switch you it could lead to even more incomprehensible errors.

## Using the indentation as a hint

In languages with `{}` style code blocks parsers shouldn't really look at indention, but what if it did.

In case of a parsing error the parser can look for the nearest indent or dedent missing any kind of brace or parenthesis and insert a opening or closing brace/bracket/parenthesis there. If the code makes sense now they can give a much clearer hint about what the programmer should do while also being able to properly parse and print errors for the rest of the file.

This will fail if the code is not indented properly, or a indentation style is used the compiler doesn't recognize.
> **Comments:**
> **username_2** (2023-07-03): One thing about ignoring successive errors is that if you're making a language server, it won't provide highlighting for stuff after the first error.  
---
### Answer by username_3 on 2023-05-20. Score: 2
The problem with missing close braces is that the compiler can't know whether the errors are indeed dependent or independent. The only clues that you didn't intend to write the below code and truly made two mistakes are things that can only be understood by humans not computers:
namespace Spaaaaaace
{
    public static class RequiredTestProtocol
    {
        public static void Test()
        {
            Console.WriteLine("As part of a required test protocol, we must run this program successfully.");
    
            static void Main(string[] args)
            {
                Test();
            }
        }
    }
}

It would be possible to have a hierarchy of syntax errors and only report errors high-up on the hierarchy if there are no errors lower-down on the hierarchy (with unbalanced brackets being below everything else), in which case the two for loop errors would likely be on the same level, but this can't be done in the general case.
---
