38 ms·

The error management was purposely build so you don't have to pass an additional parameters to know if your call failed or not. If you have to pass a parameter

The error management was purposely build so you don't have to pass an additional parameters to know if your call failed or not. If you have to pass a parameter which will be then unused (null, undefined, etc) if no error was raised then you get a redundant mechanism. I think the Zig team recognize this because they still have an old issue open for it which is still planned [0]. [0] https://github.com/ziglang/zig/issues/2647 https://github.com/ziglang/zig/issues/2647

losvedir 4y ago
I'd really like something to help with that issue. I really appreciate Zig's error handling right up until you need to pass along any info other than essentially an error code. Then you have to throw away a lot of the syntax niceties and error tools that it gives you. I understand there's complications, though, with dynamic objects being returned up the stack, possibly requiring allocation, rather than a simple enum. Rust gets this right for me, at a semantic level, where an Error is just an ADT with an arbitrary payload. However, while there's something to be said for consistency in a language and treating errors as any other values that you work with via `match` and any other ordinary language constructs, I really like that Zig has some syntactic sugar for working with it. Errors are so prevalent and necessary to deal with, they don't have to be exactly like ordinary values, and it's nice that, e.g., Zig has special handling for them in `if` statements, and ways of working with them in function signatures, and automatic error unions and such.
- skywal_l 4y ago
  To be fair, Rust also comes with some specific `if` constructs to deal with error management and has the equivalent of zig's `try` with `?`. I also like that their Result object has many methods to express how you want to specifically handle error case (all the variations of unwrap, unwrap_or, or, etc...).
throwawaymaths 4y ago
I'm saying workaround 2 in your link is honestly not that bad.
von_lohengramm 4y ago
> which is still planned Where are you getting that from? That proposal is not accepted.

losvedir 4y ago

I'd really like something to help with that issue. I really appreciate Zig's error handling right up until you need to pass along any info other than essentially an error code. Then you have to throw away a lot of the syntax niceties and error tools that it gives you. I understand there's complications, though, with dynamic objects being returned up the stack, possibly requiring allocation, rather than a simple enum. Rust gets this right for me, at a semantic level, where an Error is just an ADT with an arbitrary payload. However, while there's something to be said for consistency in a language and treating errors as any other values that you work with via `match` and any other ordinary language constructs, I really like that Zig has some syntactic sugar for working with it. Errors are so prevalent and necessary to deal with, they don't have to be exactly like ordinary values, and it's nice that, e.g., Zig has special handling for them in `if` statements, and ways of working with them in function signatures, and automatic error unions and such.

skywal_l 4y ago
To be fair, Rust also comes with some specific `if` constructs to deal with error management and has the equivalent of zig's `try` with `?`. I also like that their Result object has many methods to express how you want to specifically handle error case (all the variations of unwrap, unwrap_or, or, etc...).

throwawaymaths 4y ago

I'm saying workaround 2 in your link is honestly not that bad.

von_lohengramm 4y ago

> which is still planned Where are you getting that from? That proposal is not accepted.