Error payloads in Zig

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.

> Does the Zig language not have useful exceptions/stacktraces that can be propagated out?

Yes, it has error return traces.

In general if you have the (IMO sensible) approach of taking as few dependencies as possible and not treating them like a black box, then for any error you can simply look at the call stack and figure out the problem from reading the code during development.

Outside of that, error codes are useful for debugging code that is running on other people's machines (i.e. in production) for and for reporting reasons.

It's just stored as a [256]u8 in the struct.

  // sqlite.zig
  pub const ErrorPayload = struct {
      message: [256]u8,
  
      pub fn init(db: *c.sqlite3) @This() {
          var self = std.mem.zeroes(@This());
          var fw = std.Io.Writer.fixed(self.message[0..]);
          _ = fw.writeAll(std.mem.span(c.sqlite3_errmsg(db))) catch |err| switch (err) {
              error.WriteFailed => return self, // full
          };
          return self;
      }
  };

What more do you want than what's covered in the post?

To me, this post is proof zig doesn't need "proper support". You can already have extremely ergonomic error payloads with existing language features.

Earlier version of this post had some language feature ideas, but then I realized Zig already had all the capabilities, so I just removed that section.

For example, I used to think it'd be nice for functions to be a namespace, so I didn't have `myFunc` and `MyFuncDiagnostics`. But then I realized that the Diagnostics type doesn't need its own name; you can just put the type in the function signature, and use a function like `diagnostics.OfFunction(fn)` to extract the type from the function definition, so you can just write this:

  var diag: diagnostics.OfFunction(myFunc) = .{};
  const res = myFunc(foo, bar, &diag) catch |err| ...;

Do you want automatic inference of the error payload type? So zig creates a special tagged union error payloads type for you automatically? It seems complicated and maybe not a good idea. Do you really want your function to return an invisible 20 elements union on error? Do you want to call a someone else's function which returns an invisible 20 elements union on error? You know, maybe it's not a good idea.

You can't really easily have useful user defined payloads in errors without implicit allocations.

Best way to do it is to pass a payload pointer into the function call. You can put it into an options struct with a default null pointer that noops if you prefer the ergonomics of a kwarg.

I thought so too at first, coming from a language (Hare) where they are very easy and common, but the Diagnostics pattern isn't that bad once you expect it. Various examples: https://ziggit.dev/search?q=Diagnostics

Right. It's one thing to build the equivalent of Result into the language -- great. It's another to make it only support simple enum variants and not be extensible.

What zig really needs is a stack trace that works properly on release mode. And a way to collect the stack trace into a string at runtime so it can be saved as a log or into a db

This is just a "complex real world app code" extension of the stdlib Diagnostics pattern.

  % rg Diagnostics zig/lib/std | wc -l
  165