Why Go’s Error Handling Can’t Use Zig‑Style “try”

Problem statement

Go code frequently uses if err != nil after each call. Zig provides a try operator that propagates errors in a single line. Why doesn’t Go adopt a similar construct?

Design difference

Go’s error type is an interface:

type error interface {
    Error() string
}

Any type that implements Error() satisfies it, so the set of possible errors is open and unknown at compile time.

Zig defines errors as a compile‑time known enum:

const ConfigError = error{ FileNotFound, ParseFailed, InvalidInput };

Key dimensions

Error type : Go – runtime interface, flexible; Zig – compile‑time enum, strict.

Information carried : Go can attach arbitrary context; Zig errors are 16‑bit integers.

Compiler enforcement : Go does not require handling; Zig forces exhaustive handling.

Extension cost : Go adds new error values at zero cost; Zig requires changing the enum definition.

Why adding try to Go is problematic

Hypothetical syntax

func loadConfig(path string) (Config, error) {
    data := try os.ReadFile(path)
    cfg  := try parseJSON(data)
    return cfg, nil
}

Problem 1 – implicit return points

Each try may return early, so readers must imagine a hidden jump.

Go’s design goal is that control flow be visible in the source.

Problem 2 – limited benefit

In Zig, try is powerful because the compiler knows the full error set.

In Go, error is a black box; try would only save a few characters and would not add type safety.

Problem 3 – backward‑compatibility breakage

If os.ReadFile were changed to return a specific error set, existing code would no longer compile:

// Illustrative new signature
func ReadFile(path string) ([]byte, error) { /* returns NotFound, PermissionDenied, … */ }

// Existing call
data, err := os.ReadFile("x.txt") // type mismatch → compile error

Changing the standard library would require a massive migration across the Go ecosystem, which the language’s compatibility policy explicitly avoids.

Brief overview of Zig error handling

Zig treats errors as values and provides language constructs that make propagation cheap and safe.

// 1. Compile‑time error set
const FileError = error{ NotFound, TooBig };

// 2. Function signature declares possible errors
fn open(path: []const u8) FileError!File { … }

// 3. <code>try</code> propagates errors; the compiler tracks the path
fn readConfig() !Config {
    const f = try open("config.json"); // on failure, returns immediately
    defer f.close();                  // automatic cleanup
    return parse(f);
}

// 4. Debug mode prints a stack trace automatically
// error: NotFound
// /src/main.zig:15:23 in readConfig

Additional mechanisms: errdefer for resource cleanup when an error is returned.

Compiler enforces handling of every error value.

Practical techniques for Go developers

Because a Zig‑style try is unlikely to appear, the following patterns can reduce boilerplate while staying within Go’s model.

Helper to panic on unexpected errors

func must[T any](t T, err error) T {
    if err != nil {
        panic(err) // suitable for initialization‑like code
    }
    return t
}

// Usage
cfg := must(loadConfig("app.json"))

Combine multiple errors (Go 1.20+)

func cleanup() error {
    return errors.Join(
        closeDB(),
        closeCache(),
        flushLogs(),
    )
}

Conclusion

Go’s error model prioritises flexibility and long‑term backward compatibility. Introducing a Zig‑style try would require changing the fundamental error type, break existing code, and provide only marginal syntactic convenience. Zig, by contrast, achieves concise error propagation through compile‑time error sets and strict handling guarantees, at the cost of a less flexible error representation. The trade‑off remains: Go keeps its explicit if err != nil pattern, while Zig offers exhaustive, zero‑runtime‑overhead error handling.