[Galanwe]

From my experience, Zig is the worst at error handling.

Not that the language itself make it hard, on the contrary, but the standard library itself is littered with opinionated error handling that straight up panic with no recovery at every corner.

For instance, it was decided that the kernel returning EINVAL for any syscall is worth panicking, even though there are a lot of cases where that is recoverable. The answer from Andrew? It's the kernel's fault. Very helpful.

Quotes are cute, but their actual implementation matters more.

[Zambyte]

Quotes are cute, and I prefer them over uncited negative claims. Can you link somewhere he actually said that? Because from a quick search I find him saying:

> It should be handled on a case-by-case basis. For some syscalls, EINVAL should be unreachable because it can only mean something like an invalid pointer address being passed to the kernel, or invalid flags.

> However, as you pointed out, some kernel APIs unfortunately have decided to dual-purpose this error code to mean other things, in which case we must to handle the ambiguity by mapping it to an error code. We had to make this change with EBADF recently for some syscalls, for example.

> I do want to keep the error sets clean, however, so I am opposed to a blanket modification of all EINVAL code sites without cause.

Source: https://github.com/ziglang/zig/issues/6925#issuecomment-7214...

[Zambyte]

> We discussed this in the meeting today and decided that we'll start by changing all => unreachable to => return error.Unexpected in std.posix and std.os.

https://github.com/ziglang/zig/issues/6389#issuecomment-2895...

[johnisgood]

My problem with panics is that if it is a library (e.g. standard library), then I cannot handle the error the way I want. Let us say that you have a library that parses something. As the user of that library, you want to be able to handle these errors gracefully, you do not want the library to just panic at those parse errors. Sadly I have seen libraries do this.