6 ms·

The thing I dislike about Zig error handling is that there's no way to associate informational context with an error. Bubbling the errors up, you'll eventually

The thing I dislike about Zig error handling is that there's no way to associate informational context with an error. Bubbling the errors up, you'll eventually print out a string to the console that says "error: AccessDenied". The sysadmin/user running your software will be left baffled. Access denied... to what?! Zig is 90% of the way there with error handling, but it is extremely obvious to me that you need to be able to have error context carried with the error... it is apparently not obvious to the core Zig team[0], and this is a major impediment to my interest. Sure, if you're compiling to a microcontroller, maybe you're willing to sacrifice usability to avoid error values ever allocating... but most developers can spare an allocation for errors, especially given that error handling is generally not the hot path. [0]: https://github.com/ziglang/zig/issues/2647 https://github.com/ziglang/zig/issues/2647 (among other issues)

dilap 5y ago
Totally agree; it's almost perfect, but this is defnly needed to get to full perfection. While you can argue (as people do on that issue) that there are workarounds to carry error payload, the truth is if you don't make it ergonomic, many libraries will not do it, and that will filter down into software using those libraries, thus hurting the final resulting software. I'm hopeful this feature will eventually get added. (See also https://news.ycombinator.com/item?id=25798578 https://news.ycombinator.com/item?id=25798578)
kristoff_it 5y ago
> it is apparently not obvious to the core Zig team I think it really is not obvious once you start thinking about all the implications. Right now the recommended way of reporting extra information alongside errors is by using a "diagnostics" struct. You can see an extremely effective example of that in zig-clap, for example. https://github.com/Hejsil/zig-clap https://github.com/Hejsil/zig-clap Also this pattern was also mentioned in the issue you mentioned: https://github.com/ziglang/zig/issues/2647#issuecomment-589829306 https://github.com/ziglang/zig/issues/2647#issuecomment-5898... The advantage of this system is that the caller can decide whether error diagnostics are desirable or not. If they're not, then zig-clap doesn't waste cycles nor memory keeping track of the context in which an error happened. It's the best of both worlds in my opinion.
- coder543 5y ago
  > I think it really is not obvious once you start thinking about all the implications. No... it really is obvious. I've written quite a bit of C, C++, and Rust over the years, in addition to all sorts of garbage collected languages. I'm not writing this as an off-the-cuff thought. I've even written a similar comment before on HN about Zig's error handling. I've thought about this for a long time. It is just as obvious now as it was on day one. The fact that the Zig team keeps resisting this is just mind blowing to me. "Penny wise, pound foolish" is my opinion. The actual runtime cost here would be so entirely negligible, but its absence is a major limitation. > The advantage of this system is that the caller can decide whether error diagnostics are desirable or not. If they're not, then zig-clap doesn't waste cycles nor memory keeping track of the context in which an error happened. It's the best of both worlds in my opinion. Instead, the developer has to waste mental cycles and memory keeping track of the context on every single function call. Strongly disagree on it being the best of both worlds. For starters, every library has to decide whether they will support it or not. If the language doesn't make this a built-in part of the core error handling, then spoiler: they won't. They'll throw away all useful error context, leaving no option for the application developer to add it back. Once the context is gone, it's gone for good. You can't know what a library did to cause an AccessDenied error... you can't reach into the library and pull that context out of thin air. If every library is implementing this diagnostics pattern, then that's an equally strong argument for it to be supported at the language level. Either context is being irrevocably lost or developers are wasting time writing convoluted code. Either way, this is not the optimal solution. I have experience writing code in a lot of languages... error context is extremely important, and the "waste" of CPU cycles and memory is extremely minimal for the benefit gained. As I have hinted before, a compile-time switch to throw this information away could be a valid solution for the extremely-difficult-to-imagine situations where great error handling is unacceptably costly on performance... then it would be like Zig's "async" support, where the library developer doesn't have to color their functions based on how the end user will use it. They should return all the error information all the time, and the compiler decides whether to keep the context or throw it away and provide only the error "name". Yes, this would bring its own challenges, but seriously, this option to discard the context is completely unnecessary outside of like 8-bit microcontrollers, and probably isn't worth implementing. Just provide context all the time. Please... it's such a small ask. Looking at the links you've provided, which you have also provided in past discussions here, that pattern is extremely painful. I cannot overstate how much worse that usability is compared to the regular error handling Zig provides, and so obviously no one will ever use it. It serves as a pattern for the most desperate situations, and as a way to handwave the lack of language-level support for error context, in my opinion.
AndyKelley 5y ago
It's obvious that error context is vitally needed. What's not obvious is how to accomplish this in the language without compromising other things such as simplicity. Pick any solution, and a new set of problems rear their ugly heads. That's not to say it can't be solved. The proposal is open; neither rejected nor accepted. For especially difficult language design decisions, I like to work on other language changes that I am more confident about as a way to anchor the design, and then revisit the difficult questions, hopefully armed with more guidance from the rest of the language design being in place.

dilap 5y ago

Totally agree; it's almost perfect, but this is defnly needed to get to full perfection. While you can argue (as people do on that issue) that there are workarounds to carry error payload, the truth is if you don't make it ergonomic, many libraries will not do it, and that will filter down into software using those libraries, thus hurting the final resulting software. I'm hopeful this feature will eventually get added. (See also https://news.ycombinator.com/item?id=25798578 https://news.ycombinator.com/item?id=25798578)

kristoff_it 5y ago

> it is apparently not obvious to the core Zig team I think it really is not obvious once you start thinking about all the implications. Right now the recommended way of reporting extra information alongside errors is by using a "diagnostics" struct. You can see an extremely effective example of that in zig-clap, for example. https://github.com/Hejsil/zig-clap https://github.com/Hejsil/zig-clap Also this pattern was also mentioned in the issue you mentioned: https://github.com/ziglang/zig/issues/2647#issuecomment-589829306 https://github.com/ziglang/zig/issues/2647#issuecomment-5898... The advantage of this system is that the caller can decide whether error diagnostics are desirable or not. If they're not, then zig-clap doesn't waste cycles nor memory keeping track of the context in which an error happened. It's the best of both worlds in my opinion.

coder543 5y ago
> I think it really is not obvious once you start thinking about all the implications. No... it really is obvious. I've written quite a bit of C, C++, and Rust over the years, in addition to all sorts of garbage collected languages. I'm not writing this as an off-the-cuff thought. I've even written a similar comment before on HN about Zig's error handling. I've thought about this for a long time. It is just as obvious now as it was on day one. The fact that the Zig team keeps resisting this is just mind blowing to me. "Penny wise, pound foolish" is my opinion. The actual runtime cost here would be so entirely negligible, but its absence is a major limitation. > The advantage of this system is that the caller can decide whether error diagnostics are desirable or not. If they're not, then zig-clap doesn't waste cycles nor memory keeping track of the context in which an error happened. It's the best of both worlds in my opinion. Instead, the developer has to waste mental cycles and memory keeping track of the context on every single function call. Strongly disagree on it being the best of both worlds. For starters, every library has to decide whether they will support it or not. If the language doesn't make this a built-in part of the core error handling, then spoiler: they won't. They'll throw away all useful error context, leaving no option for the application developer to add it back. Once the context is gone, it's gone for good. You can't know what a library did to cause an AccessDenied error... you can't reach into the library and pull that context out of thin air. If every library is implementing this diagnostics pattern, then that's an equally strong argument for it to be supported at the language level. Either context is being irrevocably lost or developers are wasting time writing convoluted code. Either way, this is not the optimal solution. I have experience writing code in a lot of languages... error context is extremely important, and the "waste" of CPU cycles and memory is extremely minimal for the benefit gained. As I have hinted before, a compile-time switch to throw this information away could be a valid solution for the extremely-difficult-to-imagine situations where great error handling is unacceptably costly on performance... then it would be like Zig's "async" support, where the library developer doesn't have to color their functions based on how the end user will use it. They should return all the error information all the time, and the compiler decides whether to keep the context or throw it away and provide only the error "name". Yes, this would bring its own challenges, but seriously, this option to discard the context is completely unnecessary outside of like 8-bit microcontrollers, and probably isn't worth implementing. Just provide context all the time. Please... it's such a small ask. Looking at the links you've provided, which you have also provided in past discussions here, that pattern is extremely painful. I cannot overstate how much worse that usability is compared to the regular error handling Zig provides, and so obviously no one will ever use it. It serves as a pattern for the most desperate situations, and as a way to handwave the lack of language-level support for error context, in my opinion.

AndyKelley 5y ago

It's obvious that error context is vitally needed. What's not obvious is how to accomplish this in the language without compromising other things such as simplicity. Pick any solution, and a new set of problems rear their ugly heads. That's not to say it can't be solved. The proposal is open; neither rejected nor accepted. For especially difficult language design decisions, I like to work on other language changes that I am more confident about as a way to anchor the design, and then revisit the difficult questions, hopefully armed with more guidance from the rest of the language design being in place.