[danielparks]

He posted a follow up about error handling in Zig that I thought was interesting: https://ayende.com/blog/194466-A/looking-into-odin-and-zig-m...

I’ve seen the “clean up errors yourself” argument before, but, like the author, I don’t think it holds water. Often the correct response to errors is to panic() or pass it up the stack so the caller can deal with it or—more likely—panic() itself.

[Zababa]

I think it's nice to have two mechanisms for errors like in ML: sum types for errors that the calling function can realistically recover from, and exceptions for the rest.

[dnautics]

You can do that in zig with @panic and even convert from sum type error to an irrecoverable exception: `catch @panic("oops");`

[Zababa]

That's nice. Are the sum types checked by the compiler to ensure that you didn't miss any case?

[AndyKelley]

Yes, and you can even handle some errors, and then capture an error whose type is the subset of unhandled errors, and return that, limiting the error set of the current function to not include the handled ones. Here are a couple examples: https://github.com/ziglang/zig/blob/7d0de54ad44832589379a4bc...

You get compile errors if you try to handle an impossible error, or don't include an `else` prong (in which case the compiler tells you the full set of unhandled errors).

[Zababa]

That's a great feature. I'm constantly impressed by what Zig can do.

[squeek502]

If I understand you correctly, then yes.

    fn canError(foo: bool) !void {
        if (foo) {
            return error.Foo;
        } else {
            return error.Bar;
        }
    }

    test "canError" {
        canError(true) catch |e| switch (e) {
            error.Foo => @panic("foo!"),
        };
    }

Running `zig test` on that file would give:

    ./tmp/errors.zig:10:30: error: error.Bar not handled in switch
        canError(true) catch |e| switch (e) {
                                 ^

[Zababa]

You did understand it correctly. That's a really nice feature.

[Gaelan]

This is Rust's approach, too: realistically recoverable errors are handled with Result<T, E>, and other are handled through panics. (Panics are generally implemented as exceptions, i.e. they unwind the stack, but the compiler can also be configured to make them just abort.)

[randyrand]

C has always had Asserts for that reason.

[Zababa]

Is it idiomatic to assert things and recover from them the way people sometimes do with exceptions?

[tored]

I agree with the author that errdefer seems like the winning feature of zig. Proper error handling is the most important part of any language or system.

Unfortunately most common languages does not prioritize this. As a contractor I have dug myself thru a lot of awful code in different languages and the most common denominator is improper error handling.

[ksec]

Off Topic:

>He posted a follow up about error handling......

When I was reading the original blog I was thinking if he had any follow up, so I decide to click on archive and the homepage. And this article, somehow doesn't show up in both list. As a matter of fact I couldn't even find how to get to this blog post without your direct linking. Then it turns out it is a "FUTURE POSTS".

How does that work and why? Is this suppose to be some sort of preview before it is officially published?

[ayende]

Author here - I typically just throw things into the post queue and they drop every day. In this case, I replied to a question and it turned into a full blown post.

[ksec]

>I typically just throw things into the post queue and they drop every day.

That is a great idea. Thank You I might start doing that as well.

[danielparks]

Yeah, it’s weird. I tried stripping the key= parameter from the link when I commented, but it’s required.

The author posted the link in the comments of the original post.

[randyrand]

I dont panic nearly as much as you it seems!

Handling Errors causes us developers so confusion, because we are so used to exceptions and how poorly they were conceived.

Errors should be called Failures. It's just when a function fails to so what it says it does. Nothing more, nothing special about it!

If you call fopen() and it doesn't find the file, that's a Failure! No reason to panic! Just go create the file!