4 ms·

AFAIR, Zig has an open issue on how to pass additional context with errors, such as e.g. row & col where a syntax error happened.

by akavel 5y ago

dnautics 5y ago
To clarify I thin parent means syntax error I'm the sense of "I'm parsing a (code) file at runtime and there's a syntax error", not a language syntax error. I mean there's nothing stopping you in zig from creating a rich "error" struct and returning a union of the struct with whatever you would have done otherwise. You only lose the error return trace.
- topspin 5y ago
  "I mean there's nothing stopping you in zig from creating a rich "error" struct" Thus Rust's std::result::Result<T, E> where the E in Err(E) is anything that implements the std::result::Error trait. Rust got this right. It satisfies most use cases with the least possible noise and accommodates the weird ones easily, and does it in a std:: codified manner where no one has to wonder whether or not there is anything stopping them.
  - steveklabnik 5y ago
    (E is not required to implement that trait, it just often does)
  - dnautics 5y ago
    Have you seen what a "rich error struct union" looks like in zig? It's very easy and very legible code. I'd further bet that there are no cases when you're doing this that you want an error return trace. And the downstream handling code is very easy. If there is a problem with how it's done in zig, it's a community one: maybe the pattern needs a megaphone beside it, like examples in the main docs or tuts in the various zig tut sites that have cropped up
    - topspin 5y ago
      "Have you seen what a "rich error struct union" looks like in zig?" No, and I'm not arguing that zig hasn't done well. I do argue that Go has not; you're only non-weird choice is to fetter code with miles of "if err ==/!=" gymnastics. Traces are frequently very useful; precise traces have saved me a lot of pain in life. Lack of traces precludes nothing for me, but I have enjoyed the benefit of them enough times to acknowledge their great value.
      - dnautics 5y ago
        Traces are fantastic for unexpected errors. You don't need them, for example, when validating user input, which is the type of system where you want richer errors.

AFAIR, Zig has an open issue on how to pass additional context with errors, such as e.g. row & col where a syntax error happened.

by akavel 5y ago

AFAIR, Zig has an open issue on how to pass additional context with errors, such as e.g. row & col where a syntax error happened.

dnautics 5y ago

To clarify I thin parent means syntax error I'm the sense of "I'm parsing a (code) file at runtime and there's a syntax error", not a language syntax error. I mean there's nothing stopping you in zig from creating a rich "error" struct and returning a union of the struct with whatever you would have done otherwise. You only lose the error return trace.

topspin 5y ago
"I mean there's nothing stopping you in zig from creating a rich "error" struct" Thus Rust's std::result::Result<T, E> where the E in Err(E) is anything that implements the std::result::Error trait. Rust got this right. It satisfies most use cases with the least possible noise and accommodates the weird ones easily, and does it in a std:: codified manner where no one has to wonder whether or not there is anything stopping them.
- steveklabnik 5y ago
  (E is not required to implement that trait, it just often does)
- dnautics 5y ago
  Have you seen what a "rich error struct union" looks like in zig? It's very easy and very legible code. I'd further bet that there are no cases when you're doing this that you want an error return trace. And the downstream handling code is very easy. If there is a problem with how it's done in zig, it's a community one: maybe the pattern needs a megaphone beside it, like examples in the main docs or tuts in the various zig tut sites that have cropped up
  - topspin 5y ago
    "Have you seen what a "rich error struct union" looks like in zig?" No, and I'm not arguing that zig hasn't done well. I do argue that Go has not; you're only non-weird choice is to fetter code with miles of "if err ==/!=" gymnastics. Traces are frequently very useful; precise traces have saved me a lot of pain in life. Lack of traces precludes nothing for me, but I have enjoyed the benefit of them enough times to acknowledge their great value.
    - dnautics 5y ago
      Traces are fantastic for unexpected errors. You don't need them, for example, when validating user input, which is the type of system where you want richer errors.