Comment by dnautics
7 days ago
Zig has error unions on return types which are basically a special cased (rust enum aka sum type) of the return type with a special cased (c enum aka enumerated type), and stacktraces are only available in certain build modes.
A "diagnostics" pattern has emerged in the community to optionally request extra information about a failure. You can pass a pointer to the diagnostic (it can be on the stack) and get the extra info back. It's just a more explicit version of what would otherwise happen in a language with error payloads.
> stacktraces are only available in certain build modes.
Minor correction: stack traces are available on all build modes, but different build modes have different defaults. See: std.Options.allow_stack_tracing
Note that this "diagnostics" pattern is only meant for handling a error locally with potential extra information, or showing a more useful error to a end user of the software. For software bugs, crashes, or developer facing errors, you often don't have to do anything as zig has pretty good error traces by default.
> stacktraces are only available in certain build modes
> zig has pretty good error traces by default
These seem rather conditional. If I need to run release-fast in prod, say, do we loose these error traces (for bugs)?
You can enable error traces for release-fast builds as well, without enabling full debug info. Though the quality of call stack of course vary depending on optimization level.
1 reply →
You do, to a significant extent. Though there is always the option of running ReleaseSafe.