The problem is that in other languages, it's common to do this sort of idiom

    throw new Error("Expected foo, found bar at line " + line)

    // ...then elsewhere
    catch (e) {
      log("In file " + file + ":\n" + e.message);
    }

In zig, you can't attach arbitrary strings to errors because errors are effectively enums (in the sense of that constant names map exclusively to ints). You can only do this `try callMe() catch return error.Something` (The `return error.Something` part is zig's "equivalent" to `throw error`, but notice how I can't tack on the error message string to the error)

`try` only shortcircuits into the `catch return` expression for errors, but for cases like parsers you want to shortcircuit and bubble up error messages simultaneously. You can kinda do weird workarounds by having a pointer to an error field in your input struct and mutating that prior to returning an error value, and/or doing weird nullable-to-sentinel-value-promotion shenanigans with idioms like `callMeMaybe() orelse return someSentinel("Expected foo")` to simulate the early-return-from-expression semantics from `try callMe() catch return error.Something`.

The problem (which is a deliberate design decision) is that Zig's error unions, which have special built-in support at the syntax level, are just tagged unions with an integer payload. In other words, when you return an error (either implicitly via `try` or directly with `return error.MyError`), that error payload is just an integer indicating which error was returned. So to use OP's parser example, there's not a built-in way to attach some sort of diagnostic info to the error itself, the way you would with, for example, python exceptions. Using the built-in syntax, you can't do the equivalent of `raise ParserException(token, line_number)` and then unpack that error later in your code to display a nice error message.

The workaround would be to store that info in some sort of global struct (which has all the usual drawbacks of global variables); add a context/diagnostics parameter to your function, or manually manage your own error union in userspace, which means you lose the nice `try` syntax.