3 ms·

Can someone more knowledgeable than me in Zig explain this: > var x = try foo(); means x is equal to the result of foo() unless there was an error in the resul

Can someone more knowledgeable than me in Zig explain this: > var x = try foo(); means x is equal to the result of foo() unless there was an error in the result. > If there was an error, return from the function with the error now. > This meant that you don’t have the messy littering of if conditionals after every function that you > typically get in C, but you also don’t have the complete disaster that is exceptions in C++/C#. How is this different from exceptions? Exiting a function immediately in case a function call fails sounds exactly like an exception.

von_lohengramm 5y ago
Because it's a part of the type signature and cannot be accidentally ignored. Every possible error case must be handled when unwrapping the error value.
- hota_mazi 5y ago
  So... like checked exceptions (e.g. Java needs to declare those in the signature, and they are an integral part of said signature). The more I hear about how Zig implements it, the more it is exactly like exceptions.
  - von_lohengramm 5y ago
    It is different in implementation, for better or worse. Instead of stack unwinding, it's a part of the return value.
  - masklinn 5y ago
    > The more I hear about how Zig implements it, the more it is exactly like exceptions. It's exactly like exceptions aside from all the problematic bits of exceptions: * it is very explicit * it is much easier to interact with * it can be abstracted over (since a "result" is a reified value of a known type) * it supports but is not over-optimised for happy path or split-path scenarios * it doesn't require separate allocations or RTTI * it has a much more uniform cost model That doesn't necessarily mean it's the right system for what you usually work with, but it's a really nice way to do error handling. For an expansion of this, Brian Cantrill has a paean to this error handling style in his "falling in love with rust"[0], I can't direct-link the section but it's "1. Rust’s error handling is beautiful". [0] http://dtrace.org/blogs/bmc/2018/09/18/falling-in-love-with-rust/ http://dtrace.org/blogs/bmc/2018/09/18/falling-in-love-with-...
Zababa 5y ago
> Exiting a function immediately in case a function call fails sounds exactly like an exception. No, this would be an early return. The specificity of exceptions is that their default behavior is to bubble up through the entire stack. try in Zig only bubbles up to the calling function.
- hota_mazi 5y ago
  Ah, ok. So... you have to do the bubbling up manually if the caller cannot handle the early exit. Maybe I'm missing something but it still feels like a solution that looks like exception but is inferior to them.
  - Zababa 5y ago
    I think you are missing something, at least on the "ideological" aspect of things: it's part of the values/guarantees of Zig that all control flow is going to be explicit. On the landing page of Zig (https://ziglang.org/ https://ziglang.org/), "No hidden control flow." is the first bullet point. So "try" is the way they found to make control flow explicit, but also less painful that if (...) { return something; }. It's also a solution that's checked by the type system, exceptions usually aren't. I don't know if it's the best solution, but I can understand where they come from.

von_lohengramm 5y ago

Because it's a part of the type signature and cannot be accidentally ignored. Every possible error case must be handled when unwrapping the error value.

hota_mazi 5y ago
So... like checked exceptions (e.g. Java needs to declare those in the signature, and they are an integral part of said signature). The more I hear about how Zig implements it, the more it is exactly like exceptions.
- von_lohengramm 5y ago
  It is different in implementation, for better or worse. Instead of stack unwinding, it's a part of the return value.
- masklinn 5y ago
  > The more I hear about how Zig implements it, the more it is exactly like exceptions. It's exactly like exceptions aside from all the problematic bits of exceptions: * it is very explicit * it is much easier to interact with * it can be abstracted over (since a "result" is a reified value of a known type) * it supports but is not over-optimised for happy path or split-path scenarios * it doesn't require separate allocations or RTTI * it has a much more uniform cost model That doesn't necessarily mean it's the right system for what you usually work with, but it's a really nice way to do error handling. For an expansion of this, Brian Cantrill has a paean to this error handling style in his "falling in love with rust"[0], I can't direct-link the section but it's "1. Rust’s error handling is beautiful". [0] http://dtrace.org/blogs/bmc/2018/09/18/falling-in-love-with-rust/ http://dtrace.org/blogs/bmc/2018/09/18/falling-in-love-with-...

Zababa 5y ago

> Exiting a function immediately in case a function call fails sounds exactly like an exception. No, this would be an early return. The specificity of exceptions is that their default behavior is to bubble up through the entire stack. try in Zig only bubbles up to the calling function.

hota_mazi 5y ago
Ah, ok. So... you have to do the bubbling up manually if the caller cannot handle the early exit. Maybe I'm missing something but it still feels like a solution that looks like exception but is inferior to them.
- Zababa 5y ago
  I think you are missing something, at least on the "ideological" aspect of things: it's part of the values/guarantees of Zig that all control flow is going to be explicit. On the landing page of Zig (https://ziglang.org/ https://ziglang.org/), "No hidden control flow." is the first bullet point. So "try" is the way they found to make control flow explicit, but also less painful that if (...) { return something; }. It's also a solution that's checked by the type system, exceptions usually aren't. I don't know if it's the best solution, but I can understand where they come from.