FRESH

Hacker News

Error payloads in Zig

92 points by srcreigh

by AndyKelley

2 subcomments

In Zig, error codes are fundamentally a control flow construct, not a reporting mechanism.
The pattern here is to return something like error.Diagnostics for all errors that have been reported via diagnostics.
The only reason you'd have a different error code would be if the control flow should be different. For example error.OutOfMemory makes sense to be separate because it's a retryable error, which means it should be handled by different control flow.

by twhitmore

2 subcomments

Does the Zig language not have useful exceptions/stacktraces that can be propagated out?
At a high level, all non-trivial programming is composition. And (see principle of encapsulation) the vast majority of errors shouldn't be recovered and just need to be propagated out.
Then, to be useful, errors need enough information to be diagnosed or investigated. It seems like this should have been a straight-forward requirement in the language design.

by kristoff_it

1 subcomments

That is indeed more or less what you commonly do when you need something more than just error codes.
As an example: https://github.com/kristoff-it/ziggy/blob/852053b09a5f8f5b79...
The part about mapping every error kind to different error code in Zig is debatable. It might be useful in some cases maybe (I don't have the confidence to fully exclude it), but at the very least in my experience I never ever needed that.

by latch

1 subcomments

It wasn't clear from the examples, and the gist doesn't have a `deinit` method, so what happens if an error needs to own data?
> Here, sqlite.ErrorPayload.init saves 500 bytes of error message from sqlite
Who owns those 500 bytes and where are they being freed?

by scuff3d

5 subcomments

Continues to be a point of annoyance that Zig doesn't properly support payloads in errors.

by umairnadeem123

0 subcomment

the 'error payload' pattern feels like a good compromise between (a) enums and (b) full exceptions, esp when you want to preserve structured context. in zig specifically, do you find yourself standardizing payload shapes per module, or does it devolve into ad-hoc structs? would be interesting to see guidance on when to box/allocate vs keep payload trivially copyable.

by ozgrakkurt

1 subcomments

Why need error payloads when:
You can do validation at user interface and report actual nice errors.
And if something happens after that, you can save the stack trace into somewhere so the developer can see it. And you report unexpected error to user as that is exactly that

by grayhatter

1 subcomments

Alternative title; instead of learning a new language, I adapted it into something I'm more familiar with.
Depending on your language preference; Zig has issues[citation needed], but 1) it's still version 0 and 2) and this is the important part: who cares?
I get you have a pattern and shape you like a lot. But there's less value in that existing shape, than there is in being mildly uncomfortable, and expanding your world view and trying things in ways you wouldn't normally do.
If you tried it and didn't like it, cool, go back to the language you're already used to. But for everyone else. I'd encourage you to try doing things "wrong" for a while and seeing if you can't learn something from forcing yourself to do so.
Something especially true for a language that HN likes to pretend is just a toy and can't compete with [ language you already decided won ]

by deepriverfish

0 subcomment