[dnautics]

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.

[Zambyte]

> 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

[Cloudef]

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.

[andyferris]

> 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)?

[Cloudef]

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.

[dnautics]

oh awesome. I thought error traces were only on debug and optionally on ReleaseSafe.

[messe]

You do, to a significant extent. Though there is always the option of running ReleaseSafe.