Error Handling in Go: Stop Panicking, Start Wrapping

By Athreya aka Maneshwar on May 8, 2026. Originally published on DEV.to.
Error Handling in Go: Stop Panicking, Start Wrapping

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is free and source-available on Github. Star Us to help devs discover the project. Do give it a try and share your feedback for improving the product.

So you wrote your first Go program. It compiled. You felt powerful. Then you saw this:

file, err := os.Open("dreams.txt")
if err != nil {
    return err
}
defer file.Close()

data, err := io.ReadAll(file)
if err != nil {
    return err
}

result, err := process(data)
if err != nil {
    return err
}
Enter fullscreen mode Exit fullscreen mode

And you thought: "Wait... am I supposed to write if err != nil for the rest of my life?"

Yes, you are. But hear me out, it's actually kind of beautiful once you stop fighting it.

Why Go Did This To You (And Why It's Actually Fine)

Other languages treat errors like that one friend who shows up uninvited to your birthday party. They appear out of nowhere, ruin everything, and somebody else has to deal with them.

Go decided: errors are values. They're just things. Like strings. Or integers.

This means:

It's a tradeoff. You'll grow to appreciate it. Or you'll switch to Rust. Both are valid.

Pattern 1: Just Return It 

func loadConfig(path string) (*Config, error) {
    data, err := os.ReadFile(path)
    if err != nil {
        return nil, err
    }

    var cfg Config
    if err := json.Unmarshal(data, &cfg); err != nil {
        return nil, err
    }

    return &cfg, nil
}
Enter fullscreen mode Exit fullscreen mode

When to use it: When you have nothing useful to add and the caller already has enough context.

When NOT to use it: When the caller is going to see unexpected end of JSON input and have absolutely no idea which of the 47 JSON files in your app caused it.

Pattern 2: Wrap It Like It's 1999

fmt.Errorf with %w. This is your new best friend. Treat them well.

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

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

    return &cfg, nil
}
Enter fullscreen mode Exit fullscreen mode

Now when this fails, you get something like:

loadConfig: parsing /etc/app/config.json: unexpected end of JSON input
Enter fullscreen mode Exit fullscreen mode

The %w verb wraps the error so callers can still inspect it with errors.Is and errors.As.

Use %v instead and you've turned your error into a string.

The error has been murdered. You are the murderer.

Pattern 3: Sentinel Errors (The Named Ones)

Sometimes you want callers to check for specific errors:

var (
    ErrNotFound      = errors.New("user: not found")
    ErrUnauthorized  = errors.New("user: unauthorized")
    ErrRateLimited   = errors.New("user: rate limited, chill out")
)

func GetUser(id string) (*User, error) {
    if id == "" {
        return nil, ErrNotFound
    }
    // ...
}
Enter fullscreen mode Exit fullscreen mode

And the caller does:

user, err := GetUser(id)
if errors.Is(err, ErrNotFound) {
    return c.JSON(404, "user not found")
}
if err != nil {
    return c.JSON(500, "something exploded")
}
Enter fullscreen mode Exit fullscreen mode

errors.Is walks the wrap chain, so even if the error got wrapped 12 times on its journey, you can still identify it. It's like DNA testing for errors.

Pattern 4: Custom Error Types (When You're Feeling Fancy)

Sometimes a string isn't enough. You want to attach data. You want a struct. You want to flex.

type ValidationError struct {
    Field   string
    Message string
}

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

func validateEmail(email string) error {
    if !strings.Contains(email, "@") {
        return &ValidationError{
            Field:   "email",
            Message: "missing @ symbol, are you okay?",
        }
    }
    return nil
}
Enter fullscreen mode Exit fullscreen mode

And the caller pulls out the type:

err := validateEmail(input)
var vErr *ValidationError
if errors.As(err, &vErr) {
    fmt.Printf("Hey, your %s is broken: %s\n", vErr.Field, vErr.Message)
}
Enter fullscreen mode Exit fullscreen mode

errors.As is errors.Is's overachieving cousin. It doesn't just check, it extracts.

Pattern 5: panic and recover (The Forbidden Techniques)

You may have heard of panic. Maybe you saw it in a library and felt a chill.

Rule of thumb: If you're panicking, you should probably be returning an error instead.

Real exceptions to the rule:

func MustCompile(pattern string) *Regexp {
    re, err := Compile(pattern)
    if err != nil {
        panic(err) // genuinely fatal at startup
    }
    return re
}
Enter fullscreen mode Exit fullscreen mode

If you're using panic for normal control flow, the Go gophers will find you. They have ways.

TL;DR For The Scrollers

Situation Use This
Just bubbling it up with no extra info return err
Want to add context fmt.Errorf("doing X: %w", err)
Caller needs to check a specific error Sentinel error + errors.Is
Caller needs error data Custom type + errors.As
The world is ending panic (sparingly!)

Final Thoughts

Yes, you'll write if err != nil a lot.

But here's the thing, once you stop seeing it as boilerplate and start seeing it as a decision point, every one of those blocks becomes a tiny little moment where you, the developer, get to think: "What does failure mean here? What does the caller need to know?"

That's not a burden. That's craftsmanship.

Now go forth and wrap your errors.

If you enjoyed this, drop a 🦫 in the comments. If you didn't, write if err != nil { return err } 100 times as penance.

git-lrc
*AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.*

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

GitHub logo HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Commit



AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

See It In Action

See git-lrc catch serious security issues such as leaked credentials, expensive cloud operations, and sensitive material in log statements

git-lrc-intro-60s.mp4

Why

  • 🤖 AI agents silently break things. Code removed. Logic changed. Edge cases gone. You won't notice until production.
  • 🔍 Catch it before it ships. AI-powered inline comments show you exactly what changed and what looks wrong.
  • 🔁 Build a…
View on GitHub