Error Model

Error Models

• Joe Duffy - The Error Model
• Joe Duffy Blog - Midori language
• Zig uses error codes

Exceptions

Exceptions are problematic for a variety of reasons

• They create a extra hidden flow control mechanism
• Require mechanisms to unwind stack safely (like RAII)
  • These don't make sense to Austral linear types
• It's not clear at use site that there could be flow control change
• Anything can throw
• In use it's easy to ignore, and lead to handling being assumed high up in the call stack
• Perhaps not very amenable to SIMD, as implies branches at all function calls
• There is a non zero overhead - it's more on space than performance on CPU
• Doesn't work across ABI or language boundaries

Compiler Error Models

1. For lex and parsing, try to sync as safe as possible. Better avoid false positives than detect more errors.
2. Don’t do semantic analysis on code with parse errors. Chances it make sense is low.
3. For semantic analysis, use poisoning to catch as many valid errors as possible.

source

Discussed for the D language compiler

Not a particularly new idea, but perhaps something should use more. In most code I have made failures fail fast - by returning an error code, and letting that propogate up the call stack. Thoughts

• For a language server we want to continue
• So really you want lex/parser and perhaps some level of sematic checking to complete
• A pro is it is not necessary to return error codes
• Benefits from some "syncing" mechanism. In austral this was one of the arguments for ;
• In some ways it makes it easier to track errors, because can breakpoint the error handler
  • Rather than seeing some result code, and not knowing where it came from
• It implies the data returned may not be valid/consistant and can contain poisoned values
  • Detecting that is the case is as simple as seeing if error tracker has an error
• It may be useful to either fail or reset errors between different phases
  • Behavior could change between (say) language server and normal compilation usage
• Perhaps implies there is a filtering process for reporting errors - as one advantage of fail quickly is not screens full of errors

1.) The parser should be infallible, i.e. it always returns a parse tree. The return type of parse is not ParseTree OR Errors, it's ParseTree AND Errors. Within the parse tree there can be nodes corresponding to the errors found. This allows you to link the error back to the parsed text for a LSP/IDE environment (Language Server Protocol). You want to collect all parse errors that are not direct causes of each other so that you can report separate diagnostics to the user.

2.) Knowing when to stop collecting an error is a matter of recoverability. That could be looking for closing brace } or a keyword like var or something of that nature to stop the error parsing and restart the parser on a valid expression.

3.) Reporting errors to the user should attempt to maintain as much context as possible. Provide auto-fix capabilities through the LSP where feasible. Answer the question of why it is an error, not just stating the error. Please don't just make your error say "Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM"

4.) Be forgiving. If the language requires semicolons but the can still perfectly understand the statement without a semicolon, consider adding it for the user automatically with a formatting tool.

source

Aruadne is a "fancy compiler diagnostics crate" has pretty error reporting [https://docs.rs/ariadne/latest/ariadne/], which also try to explain the problem. It uses color on the terminal, as well as trying to point to where the problem is.

Links