Errors are values: wrapping, sentinels, and the if err != nil discipline

Errors are values, and that’s a design position

When you first write Go after a language with exceptions, the if err != nil blocks feel like noise. They’re not — they’re the entire point. In Go, error is just an interface — one method, Error() string — and an error is an ordinary value you return, inspect, store in a slice, or compare. The if err != nil ritual that newcomers mock is the point: every failure path is visible in the code that takes it. Go rejected exceptions deliberately. With exceptions, any line can transfer control to a handler pages away, so reading a function tells you nothing about its exit paths; with error values, control flow is exactly what’s written. The cost is repetition — if err != nil { return ... } everywhere — and Go accepts that cost on purpose: boring, explicit failure handling reads the same in every codebase, and the three lines are where you add context, not just bounce the error upward.

func loadConfig(path string) (*Config, error) {
    raw, err := os.ReadFile(path)
    if err != nil {
        return nil, fmt.Errorf("load config %q: %w", path, err)
    }
    cfg, err := parse(raw)
    if err != nil {
        return nil, fmt.Errorf("parse config %q: %w", path, err)
    }
    return cfg, nil
}

Each return annotates the error with what this layer was doing, so the final message reads like a causal chain: load config "/etc/app.yaml": open /etc/app.yaml: permission denied. No stack trace needed — the chain is the trace, in domain language.

Wrapping: %w builds a chain, errors.Is and errors.As walk it

fmt.Errorf with the %w verb doesn’t just format — it stores the wrapped error, giving the new error an Unwrap() error method. Stack enough layers and you have a linked list of errors. Two functions traverse it: errors.Is(err, target) walks the chain asking “is any link this exact value?” — the wrap-safe replacement for ==, and the one-token fix for the Hook’s 500s. errors.As(err, &target) walks the chain asking “is any link this type?” and copies the match out, so you can reach typed data (a *pgconn.PgError code, a *os.PathError path) without knowing how many layers wrapped it.

_, err := repo.GetProfile(ctx, id)

if errors.Is(err, sql.ErrNoRows) {      // survives any number of %w wraps
    return nil, ErrProfileNotFound
}
var pgErr *pgconn.PgError
if errors.As(err, &pgErr) && pgErr.Code == "23505" {
    return nil, ErrDuplicate            // typed data, extracted through the chain
}

The trap is %v vs %w: %v flattens the error into text and discards the chain — errors.Is returns false through it. Use %w when callers may need to inspect the cause; use %v deliberately when you want to seal the error at a boundary so callers can’t couple to internals. That choice is API design: every %w makes the wrapped error part of your contract — change sql.ErrNoRows to a different driver later and callers’ errors.Is checks silently stop matching.

Sentinel vs typed vs opaque: three coupling levels

There are three idioms, ordered by how much the caller must know. Sentinel errors — package-level values like io.EOF, sql.ErrNoRows, or your own var ErrNotFound = errors.New("not found") — are cheap (a pointer compare via errors.Is) and let callers branch on identity, but they’re permanent public API and carry no data. Typed errors — structs implementing error, like *os.PathError — carry fields (which path? which code?) and are matched with errors.As, at the cost of exporting a type callers now construct expectations around. Opaque errors — just return error, expose nothing — minimize coupling: callers can only log or propagate, and you stay free to change everything behind the message. The senior default is opaque-first: export a sentinel or a type only when a caller demonstrably needs to branch on that failure, because every exported error is a contract you’ll maintain forever.

panic is for bugs; the real killer is the swallowed error

panic unwinds the stack running deferred functions until recover stops it — or the process exits. Its job is unrecoverable programmer error: index out of range, nil-map write, “this branch is impossible.” It is not a control-flow channel for expected failures — a missing row is not a panic. Use recover only at goroutine boundaries — an HTTP server’s per-request middleware, a worker-pool wrapper — to convert “one buggy request” into a 500 instead of a dead process. And the detail that kills services: recover only works inside a deferred function of the panicking goroutine. A panic in a goroutine you spawned with go ignores every recover in the parent — it crashes the whole process. Every go func() that runs third-party or request-dependent code needs its own deferred recover.

The most common production failure isn’t a panic at all — it’s the swallowed error:

data, _ := fetch(ctx, key)        // err discarded: data is the ZERO VALUE
process(data)                     // nil-deref or empty result, far from the cause

if err := step(); err != nil {
    log.Printf("step failed: %v", err)
    // ...and execution continues as if it succeeded
}

Discard with _ and the zero value flows downstream, detonating a nil dereference or a silently empty response in code that looks innocent — the crash site and the cause are in different files. Log-and-continue is subtler: the function keeps running with broken state, and the log line scrolls past unread. The discipline: every err is either handled (branched on, compensated), returned with %w context, or — rarely — discarded with _ plus a comment saying why that’s safe. Nothing else.