let 'catch' define named error handlers

[networkimprov]

I'm the author of golang/go#27519 -- one of very few Go error handling proposals to remain open, after numerous other ideas to improve Go's error handling have been debated and discarded.

Since Zig is close to finalizing its language spec, I'd like to throw this into the ring. I've been watching Zig with interest from a distance. I'm disappointed in Go as a language, altho its tools, runtime, and stdlib are quite good.

The goal here is clear error handling inside complex business logic with a myriad of recovery schemes, some of which are shared. The construct below may seem alien to you at first sight, but it's completely natural to zillions of folks writing catch blocks in Java, Python, and Javascript. (And sure, you can approximate it with a nested function, but that is both alien to this constituency and heavy on boilerplate.)

In Zig today,
f() catch |err| switch (err) {...} can't skip code on error, a standard feature of catch,
if ... else |err| {...} skips code like standard try/catch, but yields a noisy indent cascade, and
try + errdefer is a case of catch (!) that throws unrecoverable (?) errors to the caller.

I respectfully submit that these are not the ideal semantics for a next-gen C.

Instead, let catch define named function-local error handlers. Unlike exceptions, this does not propagate errors up the stack, and ties a statement that can yield an error to a specific handler. It offers these features:

1. Multiple statements may reference a single error handler,
2. a handler may appear anywhere in the function after the statement(s) that reference it,
3. triggering a handler skips any statements between the trigger point and the handler, and
4. execution continues after the handler.

const f = fn(iPath []const u8) !void {                      // EDIT: was Go, now Zig
   var buf: [1024]u8 = undefined;

   const file|eos| = std.fs.openFileAbsolute(iPath, .{});   // path may not exist
   defer file.close();
   |eos| = file.seekTo(42);
   const len|eos| = file.read(buf);
   
   |epr| = process(buf[0..len]);                      // skip this on OS error
   
   catch eos switch (eos) {                           // handle OS error
      error.FileNotFound => |epr| = process(null),
      else => @panic(...),
   }
   catch epr {                                        // handle processing error
      std.log.println(epr);
      return;
   }

   finish();                                          // called unless catch returns
}

Zig's if (...) |val| {...} else |err| {...} syntax can get noisy:

if (f()) |val| {
   one(val);
   if (g()) |val| {
      two(val);
   } else |err| {
      fixtwo(err);
   }
} else |err| {
   fixone(err);
} 

With catch this could be either of:

const val|e1| = f();  // maybe just: val | e1
one(val);
val|e2| = g();
two(val);
catch e2 fixtwo(e2);
catch e1 fixone(e1);

one(_|e1| = f());
two(_|e2| = g());
catch e2 fixtwo(e2);
catch e1 fixone(e1);

And catch could infer the error from the preceding statement:

const val|err| = f();
catch { log(err); => 1; } // inits val to 1

const val|_| = f();
catch { => 1 }            // inits val to 1

When error var is omitted, catch is an operator like today:

const val = f() catch 1;

For any operation that yields an error which is not caught, returning an error could be implicit. That makes try unnecessary.

fn f() !void {
   const val|_| = g(); // if g() returns error, f() returns it
   |_| = h();          

   h();                // terse variants
   const val = g();    
}

We would want some built-in handler names for common cases:

|@panic| = f() // panic on error
|@log|   = f() // log error and return it
|@logc|  = f() // log error and continue

There's a lot of detail in golang/go#27519 and the requirements doc linked from it. If there's interest, I can work with folks here to massage that material into a Zig proposal.

[pixelherodev]

How does this actually change the language? Typical error handling in Zig looks like this:

const foo = bar() catch |err| switch (err) {
    error.A => {},
    else => {},
};

What would this look like with your proposal?

[networkimprov]

In the proposal,
a) multiple statements may reference a single error handler,
b) a handler may appear anywhere in the function after the statement(s) that reference it,
c) triggering a handler skips any statements between the trigger point and the handler, and
d) execution continues after the handler.

These are present in the first example above. I've added this list to the text.

@pixelherodev, your example is for a handler bound to a single statement with no intermediate statements, so it would look much the same.

[ifreund]

you can already get fairly close to this with #1717 which is accepted:

const std = @import("std");

const explode = fn() !void {
    return error.Boom;
}

const sleep = fn() !void {
    return error.CantSleep;
}

const run = fn() !void {
    return error.Tripped;
}

pub const main = fn() void {
    const blk = fn() !void {
        try explode();
        try sleep();
        try run();
    }

    blk() catch |err| switch (err) {
        ...
    };
}

[squeek502]

Seems very similar to handling errors using goto in C. Not sure I see the benefit over the status-quo, and the hidden goto seems strange. There's no precedence for goto style jumps in Zig, is there?

[ifreund]

Seems very similar to handling errors using goto in C. Not sure I see the benefit over the status-quo, and the hidden goto seems strange. There's no precedence for goto style jumps in Zig, is there?

I agree, this is literally goto with a different name. We have defer and more relevantly errdefer to handle this. Therefore, I'd be against accepting this proposal.

@ifreund

I agree, this is literally goto with a different name.

While this is mostly true, it should be noted that this proposal only allows forward jumps, so the potential for spaghetti code is reduced significantly.

We have defer and more relevantly errdefer to handle this.

Not quite. The whole point of this proposal (if I understand it correctly), is to simplify the direct handling of multiple instances of multiple failure modes within a single function. The try-errdefer combination works best if there is only a single failure mode to be handled.

That said, I do think that this proposal would make control flow sufficiently confusing that the potential benefits are probably not worth it.

[ifreund]

You're right, the semantics of the proposed syntax are slightly different than goto. However, I think they have the potential to be just as hard to follow in terms of control flow.
Consider the proposed example:

|val|e1| = f();  // maybe just: val | e1
one(val);
|val|e2| = g();
two(val);
catch e2 fixtwo(e2);
catch e1 fixone(e1);

and a more idiomatic version of the "status quo" snippet:

    const val = f() catch |err| {
        fixone(err);
        return;
    };
    one(val);
    const val2 = g() catch |err| {
        fixtwo(err);
        return;
    };
    two(val2);

The control flow in the second example is in my opinion far easier to understand without becoming cumbersome. I think that goto-esque jumps in control flow violate the zig zen, in particular:

• Communicate intent precisely.
• Favor reading code over writing code.
• Reduce the amount one must remember.

[networkimprov]

Isaac, I believe you added returns which don't appear in my code. If you change them to goto and add a label, then it would be the same ;-)

Agreed that this, and traditional exceptions, entail an implicit goto. But so do if, else, and for.

You could indent my second example to indicate what code is skipped on error (altho that doesn't work for my first example, where the first catch can invoke the second):

val|e1| = f();
   one(val);
   val|e2| = g();
      two(val);
   catch e2 fixtwo(e2);
catch e1 fixone(e1);

[ifreund]

ok, perhaps this is closer to the control flow you intended?

    const val = f() catch |err| fixone(err);
    one(val);
    const val2 = g() catch |err| fixtwo(err);
    two(val2);

if not, my question become how does the program continue after the catch statements if it doesn't return and val/val2 are not initialized?

|val|e1| = f();  // maybe just: val | e1
one(val);
|val|e2| = g();
two(val);
catch e2 fixtwo(e2);
catch e1 fixone(e1);
// I guess execution continues here

but what is done if we errored? If fixtwo() initializes val then my example above is clearer and more concise. If not, I'm really not sure why you don't just return. I don't see a how a hypothetical function would be able to continue without the two variables it tried and failed to initialize.

[networkimprov]

It's a contrived example to demonstrate the noise of if (...) |val| {...} else |err| {...} and unwrapping in general. My first example is more representative of authentic catch handler usage. If you can suggest ways to Zigify it, I'd be glad to rev it.

[ifreund]

Here's a zig version of your first example in go. I'm not too familiar with go so feel free to correct me if i've gotten something wrong. This also depends on #1717

const main = fn() !void {
    var buf: [1024]u8 = undefined;

    const readToBuf = fn (buf: []u8) ![]u8 {
        const file = try std.fs.openFileAbsolute("/path/to/file", .{});
        defer file.close();

        try file.seekTo(42);

        const len = try file.read(buf);

        return buf[0..len];
    };

    const maybe_slice = readToBuf(&buf) catch |err| switch (err) {
        error.FileNotFound => null,
        else => return err,
    };

    try process(maybe_slice);

    finish();
}

Edit: fixed some mistakes

[networkimprov]

Thanks! I rev'd the issue to use Zig, plus new syntax for catch handlers. I also changed my other examples to use const val|err| from |val|err|.

Re the use of nested functions as a sort of try {...} block with a single error handler, I rather doubt many ppl would code that way. The goal here is to make it easy to recover from errors locally when at all possible.