| The plot seems to get real lost in the article. Sure … it is true that Go errors can carry data, and Zig ones perhaps do not, but I don't see how that is what disqualifies a `try` from being possible. Rust's errors are rich, and Rust had `try!` (which is now just `?`). The article's reasoning around rich errors seems equally muddled. > In Zig, there's no equivalent. If both calls fail with error.FileNotFound, the error value alone can't tell you which file was missing. Which is why I'm not a huge fan of Zig's error type … an int cannot convey the necessary context! (Sometime I'd've thought C had so thoroughly demonstrated as bad with, e.g., `mkdir` telling people "No such file or directory." — yeah, no such directory, that's why I'm calling `mkdir` — that all new designs would not be limited to using integer error codes.) But then we go for … > Zig's answer is the Error Return Trace: instead of enriching the error value, the compiler tracks the error's path automatically. But the error's "path" cannot tell you what file was missing, either… > It tells you where the error traveled, not what it means. Rather than enriching the error value, Zig enriches the tooling. Sure … like, again, a true-ish statement (or opinion), but one that just doesn't contribute to the point, I guess? A backtrace is also useful, but having the exact filename is useful, too. It depends on the exact bug that I'm tracking: sometimes the backtrace is what I need, sometimes the name of the missing file is what I need. Having both would be handy, depending on circumstance, and the call stack alone does not tell you the name of the missing file. … how does either prevent a `try` statement? We try to argue that somehow the stdlib would need to change, but I do not see how that can be. It seems like Go could add try, as syntactic sugar for the pattern at the top of the article. (& if the resulting types would have type errored before, they could after sugaring, etc.) |