4 ms·
As far as I know Zig errors can't carry any data along. It's nice having more details available about the failure. Take for example if you call to an OS API an
by ziml77 3y ago
As far as I know Zig errors can't carry any data along. It's nice having more details available about the failure.
Take for example if you call to an OS API and it returns an error that wasn't documented to be returned from that function. You can't return that code up the callstack using Zig's error mechanism. Instead there's functions such as unexpectedErrno and unexpectedError. Those call the appropriate method to get a string representation of the error and call std.debug.print to display it, then they just return error.Unexpected.
That means that the caller doesn't have any control over how the error is displayed. Meanwhile in Rust, you can add an UnexpectedError variant to your enum and let it carry an error code with it. The caller can then display that error however they want.
I don't hate Zig's error handling by any means, but personally I think Rust does it better. I'm happy to see that C++ seems to be going with the Rust way by adding a Result-like type std::expected.
- RGBCube 3y agoBoth have their issues, but I think the perfect error handling mechanism would be something like the Zig way with additional data.