{"id":466,"date":"2026-07-16T05:03:42","date_gmt":"2026-07-16T05:03:42","guid":{"rendered":"https:\/\/abrarqasim.com\/blog\/go-error-handling-2026-the-patterns-i-actually-ship\/"},"modified":"2026-07-16T05:03:42","modified_gmt":"2026-07-16T05:03:42","slug":"go-error-handling-2026-the-patterns-i-actually-ship","status":"publish","type":"post","link":"https:\/\/abrarqasim.com\/blog\/go-error-handling-2026-the-patterns-i-actually-ship\/","title":{"rendered":"Go Error Handling in 2026: The Patterns I Actually Ship"},"content":{"rendered":"

Confession: I spent two hours last Tuesday tracking down a bug that turned out to be a nil pointer three call sites down from where the error surfaced. My stack trace was fine. My error wrapping<\/em> was garbage. The message printed sql: no rows in result set<\/code> at the top of a handler and I couldn’t tell which of four queries fired it.<\/p>\n

I’ve been shipping Go for years and my error handling still leaks. So over the past few months I’ve been tightening it. Cutting the if err != nil<\/code> ceremony where it doesn’t earn its keep, wrapping consistently, and finally getting errors.Is<\/code> and errors.As<\/code> right in my head. This post is what I actually run in production in 2026, warts included.<\/p>\n

Short version for the impatient: wrap every error at every boundary with %w<\/code>, use typed errors for anything a caller might branch on, and stop logging errors before you return them. If you want the code, keep reading.<\/p>\n

The if err != nil<\/code> ceremony I stopped writing everywhere<\/h2>\n

The classic Go complaint is that half your code is if err != nil { return err }<\/code>. I used to defend that. I don’t anymore, and it’s not because the pattern is wrong. It’s because a lot of those returns weren’t doing anything useful.<\/p>\n

Here’s what most of my HTTP handlers looked like a year ago:<\/p>\n

func getUser(w http.ResponseWriter, r *http.Request) {\n    id, err := strconv.Atoi(r.PathValue("id"))\n    if err != nil {\n        http.Error(w, err.Error(), 400)\n        return\n    }\n    user, err := db.GetUser(r.Context(), id)\n    if err != nil {\n        http.Error(w, err.Error(), 500)\n        return\n    }\n    if err := json.NewEncoder(w).Encode(user); err != nil {\n        log.Println(err)\n    }\n}\n<\/code><\/pre>\n
Every error handled the same generic way. No wrapping. No context. Just a raw message to the client and a naked log.Println<\/code> if the encode fails.<\/p>\n
Now I lean on a tiny helper per package that centralizes the pattern:<\/p>\n
func writeErr(w http.ResponseWriter, r *http.Request, err error) {\n    var httpErr *HTTPError\n    if errors.As(err, &httpErr) {\n        http.Error(w, httpErr.Message, httpErr.Status)\n        return\n    }\n    slog.ErrorContext(r.Context(), "handler error", "err", err)\n    http.Error(w, "internal error", 500)\n}\n<\/code><\/pre>\n
The handlers get thinner and the error path always has structure. That’s what I care about. Not deleting if err != nil<\/code> for the sake of it.<\/p>\n
Wrapping with %w<\/code>: what actually changed my debugging<\/h2>\n
fmt.Errorf(\"...: %w\", err)<\/code> sounds boring. It’s the single change that dropped my average time-to-root-cause the most in the last year.<\/p>\n
The rule I follow: every function that returns an error from another function wraps it with %w<\/code> and adds one sentence of context<\/strong>. Not two. Not zero. One.<\/p>\n
func loadInvoice(ctx context.Context, id int64) (*Invoice, error) {\n    inv, err := db.getInvoice(ctx, id)\n    if err != nil {\n        return nil, fmt.Errorf("load invoice %d: %w", id, err)\n    }\n    items, err := db.getItems(ctx, id)\n    if err != nil {\n        return nil, fmt.Errorf("load items for invoice %d: %w", id, err)\n    }\n    inv.Items = items\n    return inv, nil\n}\n<\/code><\/pre>\n
When something fails four layers deep, I now get a message like handle checkout POST: load invoice 4218: get items for invoice 4218: sql: no rows in result set<\/code>. The chain reads top-down like a Russian doll and I know exactly which query blew up.<\/p>\n
The Go blog’s working with errors in Go 1.13 post<\/a> is still the canonical reference. If you’re reading it for the first time, read it twice. The %w<\/code> verb changed the language more than most people realize.<\/p>\n
errors.Is<\/code> vs errors.As<\/code>: the split I got wrong for a year<\/h2>\n
I mixed these up embarrassingly often. Here’s the version that finally stuck in my head:<\/p>\n