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 els

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`.