Forem: Clara Bennett

Error Handling in Go Is Not Boring — Here's Why

Clara Bennett — Wed, 18 Feb 2026 21:02:58 +0000

I've seen the memes. if err != nil repeated fifty times. Go's error handling is "verbose." It's "tedious." It's "boring."

I used to agree. Then I spent a year debugging production services and changed my mind completely.

Every `if err != nil` Is a Decision Point

Here's what people miss: each error check forces you to think about failure at the exact moment it might happen. What do you do with this error? Wrap it? Log it? Return it? Retry? Ignore it?

Compare that to languages where you throw exceptions and hope someone catches them three stack frames up. Or worse — nobody catches them, and your service dies with a stack trace that tells you nothing useful about why.

f, err := os.Open(path)
if err != nil {
    return fmt.Errorf("loading config from %s: %w", path, err)
}

That's not boilerplate. That's context. When this error surfaces in a log at 3am, you'll know exactly what was happening and why.

Error Wrapping Is an Art

The real skill isn't handling errors — it's wrapping them well. Since Go 1.13 gave us %w, we can build error chains that read like a story:

starting server: loading config from /etc/app.yaml: open /etc/app.yaml: permission denied

Read that left to right. You know the whole story. No stack trace needed. No debugger needed.

I started treating error messages like commit messages: be specific, add context, future-you will be grateful.

Here's a pattern I use everywhere:

func loadConfig(path string) (*Config, error) {
    data, err := os.ReadFile(path)
    if err != nil {
        return nil, fmt.Errorf("reading config file %s: %w", path, err)
    }

    var cfg Config
    if err := json.Unmarshal(data, &cfg); err != nil {
        return nil, fmt.Errorf("parsing config from %s: %w", path, err)
    }

    if err := cfg.Validate(); err != nil {
        return nil, fmt.Errorf("invalid config in %s: %w", path, err)
    }

    return &cfg, nil
}

Three error checks. Three different contexts. If any of them fails, the caller gets a clear message about what failed and where.

Sentinel Errors and `errors.Is`

Go 1.13 also brought us errors.Is and errors.As, which let you check wrapped errors without losing context:

if errors.Is(err, os.ErrNotExist) {
    // file doesn't exist — create a default config
    return defaultConfig(), nil
}

This works even if the error was wrapped multiple times. You get structured error handling without losing the human-readable chain.

Custom Error Types When You Need Them

Sometimes a string isn't enough. When callers need to make decisions based on error details, use a custom type:

type ValidationError struct {
    Field   string
    Message string
}

func (e *ValidationError) Error() string {
    return fmt.Sprintf("validation failed on %s: %s", e.Field, e.Message)
}

Then callers can use errors.As to extract the details:

var ve *ValidationError
if errors.As(err, &ve) {
    // respond with a 400 and the specific field that failed
    http.Error(w, ve.Message, http.StatusBadRequest)
    return
}

The Anti-Patterns

A few things I've learned not to do:

Don't just log.Fatal(err) everywhere. That's the Go equivalent of catching exceptions with System.exit(1). Handle the error or return it — don't kill the process.

Don't wrap without adding context. return fmt.Errorf("%w", err) adds nothing. Either add context or return the error as-is.

Don't ignore errors silently. If you're discarding an error, at least make it explicit:

_ = writer.Close() // best-effort cleanup, error intentionally ignored

The Honest Take

Is Go error handling verbose? Yeah. Does it produce more lines of code? Absolutely. But those lines aren't wasted — they're insurance. Every wrapped error is a breadcrumb you're leaving for the person who has to debug this at 3am.

And that person might be you.

So next time you type if err != nil, don't sigh. You're doing the work that matters.

Originally posted on my blog. I write about Go, distributed systems, and practical engineering.

Why I Write Go

Clara Bennett — Sun, 15 Feb 2026 21:54:23 +0000

I didn't pick Go because it was trendy. I picked it because I was tired.

Tired of dependency hell. Tired of 200MB Docker images for a script that checks if a port is open. Tired of reading framework docs longer than the code I wanted to write.

Go gave me something I didn't know I needed: permission to be simple.

One binary. Cross-compile it. Ship it. Done. No runtime, no virtualenv, no "works on my machine." It just runs.

I build CLI tools — small, sharp utilities that do one thing well. portcheck tells you if a port is open. jsonpretty makes JSON readable. envdiff compares environment files. None of them need a README longer than a tweet.

Go makes that kind of work fun. The standard library is massive. net/http is production-ready out of the box. Error handling is explicit — annoying at first, then you realize it saved you from three silent bugs you would've shipped in Python.

And goroutines? I wrote a concurrent HTTP prober in like 40 lines. Try doing that cleanly in most languages.

Is Go perfect? Nah. Generics came late. The error handling verbosity is real. And sometimes I miss a good map/filter/reduce chain.

But every time I go build and get a single binary I can scp to a server and run — no questions asked — I remember why I'm here.

Go doesn't try to be everything. That's exactly why it works for me.

5 Small Go Patterns That Make Your Code Instantly Cleaner

Clara Bennett — Sun, 15 Feb 2026 16:51:13 +0000

After writing Go for a while, I've noticed a few small patterns that consistently make code easier to read and maintain. None of these are groundbreaking — but that's the point. Clean code is built from simple habits.

1. Return early, stay flat

Instead of nesting, flip the condition and return:

// ❌ Nested
func process(data []byte) error {
    if data != nil {
        if len(data) > 0 {
            // do work...
            return nil
        }
        return fmt.Errorf("empty data")
    }
    return fmt.Errorf("nil data")
}

// ✅ Early returns
func process(data []byte) error {
    if data == nil {
        return fmt.Errorf("nil data")
    }
    if len(data) == 0 {
        return fmt.Errorf("empty data")
    }
    // do work...
    return nil
}

2. Accept interfaces, return structs

This is idiomatic Go. Your functions should accept the narrowest interface they need, but return concrete types:

// ✅ Accept interface
func ReadAll(r io.Reader) ([]byte, error) {
    // ...
}

// ✅ Return concrete type
func NewServer(addr string) *Server {
    return &Server{addr: addr}
}

This keeps your API flexible for callers while giving them full access to the returned type.

3. Use `fmt.Errorf` with %w for error wrapping

Since Go 1.13, always wrap errors with context:

// ❌ Context lost
if err != nil {
    return err
}

// ✅ Wrapped with context
if err != nil {
    return fmt.Errorf("reading config: %w", err)
}

Now callers can still use errors.Is() and errors.As() to inspect the chain.

4. Table-driven tests

If you're writing multiple test cases for the same function, use a table:

func TestAdd(t *testing.T) {
    tests := []struct {
        name string
        a, b int
        want int
    }{
        {"positive", 2, 3, 5},
        {"zero", 0, 0, 0},
        {"negative", -1, -2, -3},
    }
    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            if got := Add(tt.a, tt.b); got != tt.want {
                t.Errorf("Add(%d, %d) = %d, want %d", tt.a, tt.b, got, tt.want)
            }
        })
    }
}

Adding a new test case is just one more line in the slice. Clean, scalable, easy to read.

5. Use `context.Context` as the first parameter

Any function that does I/O or could be cancelled should take a context:

func FetchUser(ctx context.Context, id string) (*User, error) {
    // ...
}

It's the standard convention, and it makes your code composable with timeouts, cancellation, and tracing from day one.

None of these will win you style points at a conference. But they'll make your codebase something your teammates (and future you) actually enjoy working with. That's the real win.

What small Go patterns do you find yourself reaching for? Drop them in the comments 👇