This seems kinda contrived. In practice that "ERROR DATA" tends not to exist. Unexpected errors almost never originate within the code in question. In basically all cases that "ERROR DATA" is just recapitulating the result of a system call, and the OS doesn't have any data to pass.
And even if it did, interpreting the error generally doesn't every work with a microscope over attached data. You got an error from a write. What does the data contain? The file descriptor? Not great, since you really want to know the path to the file. But even then, it turns out it doesn't really matter because what really happened was the storage filled up due to a misbehaving process somewhere else.
"Error data" is one of those conceits that sounds like a good idea but in practice is mostly just busy work. Architect your systems to fail gracefully, don't fool yourself into pretending you can "handle" errors in clever ways.
That's not error data, that's (one level of) a stack trace. And you can do that in zig, but not by putting call stack data into error return codes.
The conflation between exception handling and error flagging (something that C++ did largely as a mistake, and that has been embraced by managed runtimes like Python or Java) is actually precisely what this feature is designed to untangle. Exception support actually turns out to have very non-trivial impact on the generated code, and there's a reason why languages like Rust and Zig don't include them.
> That's not error data, that's (one level of) a stack trace.
They're not talking about the stack trace, but about the common case where the error is not helpful without additional information, for example a JSON parsing library that wants to report the position (line number) in the string where the error appears.
There's no way of doing that in Zig, the best you can do is return a "ParseError" and build you own, non-standard diagnostic facilities to report detailed information though output arguments.
Another way to look at this example is that, for the parser, this is not an error. The parser is doing its job correctly, providing an accurate interpretation of its input, and for the parser, this is qualitatively different from something that prevents it doing its job (say, running out of memory).
At the next level up, though, there might be code that expects to be able to read a JSON config file at a certain location, and if it fails, it’s reasonable to report which file it tried to read, the line number, and what the error was.
Sure, but that's a different level with different considerations. The JSON parser shouldn't care about things like ‘files’ with ‘locations’; maybe it's running on some little esp8266 device that doesn't have such things.
Error data should specify where the error occurred and what failed. So you'll know which file had a problem, and that the problem in question was a failure to write. From that you can make the inference that maybe the disk is full, etc.
And even if it did, interpreting the error generally doesn't every work with a microscope over attached data. You got an error from a write. What does the data contain? The file descriptor? Not great, since you really want to know the path to the file. But even then, it turns out it doesn't really matter because what really happened was the storage filled up due to a misbehaving process somewhere else.
"Error data" is one of those conceits that sounds like a good idea but in practice is mostly just busy work. Architect your systems to fail gracefully, don't fool yourself into pretending you can "handle" errors in clever ways.