Error Message Improvement: Introduce `@errorOrigin`

Hey Zig enthusiasts,

I've been spending quite some time wrangling with errors and their origins lately, and thought of a potential enhancement to our beloved language.

The Idea:

What if we had a way, sort of a middle-ground between the granular @errorReturnTrace and the succinct @errorName, to quickly pinpoint where an error was birthed? Enter @errorOrigin.

The Rationale:

Now, @errorReturnTrace is fantastic for in-depth investigations, but sometimes it can feel like using a sledgehammer to crack a nut. When issues stem from a third-party module, what often matters most is pinpointing where the error was first received in our module, rather than tracing its deeper origins. In these cases, a snapshot of the error's entry point into our code might be all we need.

The proposed @errorOrigin would produce a struct containing file and line. Here's how it works:

When the error is raised within the same module where @errorOrigin is invoked, the line highlights where the error was initially return-ed.
If the error originates from another module, the line designates the point where our module first encountered the error from that external source.

Perks of Having `@errorOrigin`:

Streamlined Debugging: Nailing down the error's origin without the dance of sifting through a full trace.
Less Noise, More Signal: For times when the detailed trace feels TMI, this brings clarity.
Clarity on Interactions: Invaluable when the hiccup is linked to an external library, shining light on potential missteps.

Quick Peek:

To illustrate the utility of @errorOrigin, let's dive into a brief example. Imagine you're interacting with an external library (like parsing a UUID) and handling another routine error within the same module. With @errorOrigin, the source of these errors becomes immediately transparent:

const std = @import("std");
const UUID = @import("uuid.zig").UUID;

pub fn main() void {
    foo() catch |err| {
        std.debug.print("got error: {s} at {}\n", .{@errorName(err), @errorOrigin(err)});
    };
    baz() catch |err| {
        std.debug.print("got error: {s} at {}\n", .{@errorName(err), @errorOrigin(err)});
    };
}

fn foo() !void {
    try bar();
}

fn bar() !void {
    const uuidStr = "f47ac10b-58cc-4372-a567-0e02b2c3d47q";
    _ = try UUID.parse(uuidStr);
}

fn baz() !void {
    return error.FileNotFound;
}

% zig build run
got error: InvalidUUID from main.zig:19
got error: FileNotFound from main.zig:23

Line main.zig:19 is where the external library failed to parse the UUID:

    _ = try UUID.parse(uuidStr);

While line main.zig:23 directly signals our own error:

    return error.FileNotFound;

I'm aware that the project typically refrains from entertaining Language Proposals. However, seeing the designated "Error message improvement" category sparked my inclination to share this idea, given its relevance to the theme. My apologies if I've misinterpreted the scope or intent!

This is just me thinking aloud, "Wouldn't it be neat if Zig had this feature?" 😄

Cheers to the incredible work the Zig community does and for always pushing the boundaries!

Best wishes, Joel Jakobsson

Expected Output

got error: InvalidUUID from main.zig:19 got error: FileNotFound from main.zig:23

ziglang / zig