1. 30
  1. 1

    I slightly changed my mind about error reporting after implementing a parser myself.

    Yes, getting all syntax errors at once is nice, but it tends to considerably bloat the code. So I just try to generate a precise message on the first error and exit.

    1. 3

      (Whoa, I am putting my hat on!)

      This is mostly about what you value.

      People praise Rust’s error reporting. Also, most compiler projects put some value on implementation simplicity. These two facts are related. Rust’s error reporting is superb, because Rust has near complete disregard for implementation simplicity. According to Rust project’s value as I understand it, as long as it’s simple for users, implementation can be arbitrarily complex almost without limit. This is different from most other projects, also this is probably not what you want.

      1. 1

        Exhibit A: Rust does this. “notice the capitalization”.

        1. 1

          This is a type error. Do you have a reference about how Rust handles parse error?

          1. 2

            Parse errors in Rust are handled by the strategy of special-casing known issues, so it’s a mixed bag. If you feed it randomly broken code, you’ll get the usual crappy “expected x or y, but found z”. But there are cases where it will try a fix and re-parse. There are cases where it’ll go extra mile to show a good error, e.g. for unbalanced parenthesis or missing brackets it tries to guess which one was missing.

            1 | fn foo() {}}
              |          --^ unexpected closing delimiter
              |          |
              |          this block is empty, you might have not meant to close it
        2. 1

          Sorry, I didn’t articulate it well the first time. Trying again:

          • I still very much appreciate getting all syntax errors at once
          • for my (very limited use case) implementing a full-blown error recovery wasn’t worth it
          • having faced the complexity of it I have more compassion for “line N: syntax error”.