Handling errors in Go - Deep Dive

Overview - Handling errors

What is it?

Handling errors in Go means writing code that can detect when something goes wrong and respond properly. Instead of crashing or ignoring problems, Go programs check for errors and decide what to do next. This helps programs stay reliable and clear about what failed. Errors are values in Go, so you can pass them around and handle them like any other data.

Why it matters

Without proper error handling, programs can fail silently or crash unexpectedly, causing frustration and data loss. Handling errors lets programs recover gracefully or inform users clearly about issues. This makes software more trustworthy and easier to maintain. Imagine a calculator that just stops working without explanation; error handling prevents that kind of surprise.

Where it fits

Before learning error handling, you should understand basic Go syntax, functions, and variables. After mastering error handling, you can explore advanced topics like custom error types, error wrapping, and concurrency-safe error management.

Mental Model

Core Idea

Errors in Go are just values returned by functions that you must check and handle explicitly to keep your program running smoothly.

Think of it like...

Handling errors in Go is like checking the fuel gauge before a car trip; if you ignore it, you might run out of gas unexpectedly, but if you check and plan, you avoid getting stranded.

┌─────────────┐      ┌───────────────┐      ┌───────────────┐
│ Call Func   │─────▶│ Receive Result │─────▶│ Check for Err │
└─────────────┘      └───────────────┘      └───────────────┘
                                      │
                                      ▼
                             ┌─────────────────┐
                             │ Handle or Return │
                             └─────────────────┘

Build-Up - 7 Steps

1

Foundation

What is an error in Go

Concept: Errors are values that describe something went wrong during a function's execution.

In Go, errors are represented by the built-in error type, which is an interface. Functions often return an error as the last return value. If the error is nil, it means no problem happened. If not nil, it means something went wrong. Example: func divide(a, b int) (int, error) { if b == 0 { return 0, errors.New("cannot divide by zero") } return a / b, nil }

Result

The function returns a result and an error value. If b is zero, the error is not nil and explains the problem.

Understanding that errors are just values helps you see error handling as a normal part of data flow, not a special case.

2

Foundation

Checking errors after function calls

Concept: You must always check the error returned by a function before using the other results.

When you call a function that returns an error, you write code to test if the error is nil. If it is not nil, you handle it, for example by returning it or printing a message. Example: result, err := divide(10, 0) if err != nil { fmt.Println("Error:", err) return } fmt.Println("Result:", result)

Result

The program prints the error message and stops before using the invalid result.

Knowing to always check errors prevents bugs and crashes caused by ignoring problems.

3

Intermediate

Creating custom error messages

🤔Before reading on: do you think you can create errors with any message you want? Commit to your answer.

Concept: You can create errors with custom messages to explain exactly what went wrong.

Go provides the errors.New function to create simple error values with a message. You can also use fmt.Errorf to format error messages with variables. Example: if b == 0 { return 0, fmt.Errorf("cannot divide %d by zero", a) }

Result

The error message includes the value of a, making it clearer what caused the error.

Custom error messages improve debugging and user feedback by giving precise information about failures.

4

Intermediate

Using multiple return values for errors

🤔Before reading on: do you think Go uses exceptions or multiple return values for errors? Commit to your answer.

Concept: Go uses multiple return values instead of exceptions to handle errors explicitly.

Unlike some languages that throw exceptions, Go functions return errors as a second value. This forces the programmer to handle errors immediately and clearly. Example: func readFile(name string) ([]byte, error) { data, err := os.ReadFile(name) if err != nil { return nil, err } return data, nil }

Result

The caller must check the error before using the data, making error handling visible and explicit.

Understanding Go's explicit error returns helps you write clearer and more reliable code by avoiding hidden failures.

5

Intermediate

Propagating errors up the call stack

🤔Before reading on: do you think you should handle every error immediately or sometimes pass it up? Commit to your answer.

Concept: Sometimes you don't handle an error directly but pass it up to the caller to decide what to do.

If your function cannot fix the error, return it to the caller. This is called error propagation. Example: func processFile(name string) error { data, err := readFile(name) if err != nil { return err // pass error up } // process data return nil }

Result

The error moves up the call chain until some function handles it properly.

Knowing when to propagate errors keeps your code clean and lets higher-level functions decide how to respond.

6

Advanced

Wrapping errors with additional context

🤔Before reading on: do you think errors can carry extra information beyond a message? Commit to your answer.

Concept: You can wrap errors to add context while preserving the original error for debugging.

Go 1.13 introduced error wrapping with fmt.Errorf and the %w verb. Example: if err != nil { return fmt.Errorf("reading config failed: %w", err) } This keeps the original error inside the new one, allowing unwrapping later.

Result

Errors show a chain of causes, making it easier to trace the root problem.

Wrapping errors helps maintain detailed error information across multiple layers of your program.

7

Expert

Using sentinel and typed errors effectively

🤔Before reading on: do you think all errors should be compared by message text? Commit to your answer.

Concept: Sentinel errors are predefined error variables; typed errors are custom error types for precise error handling.

Sentinel errors let you compare errors by identity, not message. Example: var ErrNotFound = errors.New("not found") Typed errors implement the error interface with extra fields. Example: type MyError struct { Code int Msg string } func (e MyError) Error() string { return e.Msg } Using errors.Is and errors.As helps check wrapped errors correctly.

Result

You can write code that reacts differently to specific error types or sentinel values.

Understanding sentinel and typed errors prevents fragile error checks and enables robust error handling strategies.

Under the Hood

Go treats errors as values implementing the error interface, which has a single Error() string method. When a function returns an error, it is just returning a value like any other. The caller must check this value explicitly. Internally, error wrapping stores the original error inside a new error value, allowing unwrapping with errors.Unwrap. The runtime does not throw exceptions; it relies on explicit checks.

Why designed this way?

Go's designers wanted to avoid hidden control flow caused by exceptions, which can make code harder to follow and debug. Returning errors explicitly makes error handling visible and straightforward. This design trades off some verbosity for clarity and reliability. Alternatives like exceptions were rejected to keep the language simple and predictable.

┌───────────────┐
│ Function Call │
└──────┬────────┘
       │ returns
       ▼
┌───────────────┐
│ (Result, Err) │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ if Err != nil │
└──────┬────────┘
       │ handle or propagate
       ▼
┌───────────────┐
│ Continue Flow │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think ignoring an error in Go is safe if the program seems to work? Commit yes or no.

Common Belief: If the program runs fine, ignoring errors is okay and saves code clutter.

Reality: Ignoring errors can cause hidden bugs, data corruption, or crashes later because problems go unnoticed.

Why it matters: Silent failures make debugging very hard and can cause serious issues in production software.

Quick: Do you think Go uses exceptions like Java or Python? Commit yes or no.

Common Belief: Go handles errors with exceptions that jump out of functions automatically.

Reality: Go does not have exceptions; it uses explicit error return values that must be checked.

Why it matters: Expecting exceptions leads to missing error checks and fragile code.

Quick: Do you think comparing error messages as strings is a good way to check errors? Commit yes or no.

Common Belief: Comparing error text strings is the best way to identify specific errors.

Reality: Comparing error strings is fragile; errors should be compared by sentinel variables or types using errors.Is and errors.As.

Why it matters: String comparisons break easily if messages change, causing incorrect error handling.

Quick: Do you think wrapping errors loses the original error information? Commit yes or no.

Common Belief: Wrapping errors replaces the original error, so you lose details about the root cause.

Reality: Wrapping preserves the original error inside, allowing you to unwrap and inspect it later.

Why it matters: Knowing this helps maintain detailed error chains for better debugging.

Expert Zone

1

Errors can carry stack traces if you use third-party packages, but Go's standard errors do not include them by default.

2

Using errors.Is and errors.As correctly requires understanding how error wrapping works internally.

3

Returning nil for error means success, but returning a non-nil error with zero values for other returns is a common pattern to signal failure clearly.

When NOT to use

Explicit error returns are not suitable for truly exceptional, unrecoverable conditions where panics are more appropriate. For example, programmer mistakes or corrupted internal state should use panic instead. Also, for very complex error handling, consider structured logging or error reporting tools instead of just returning errors.

Production Patterns

In production Go code, errors are often wrapped with context to aid debugging. Functions return errors up the call stack until a top-level handler logs or recovers. Sentinel errors and typed errors are used to distinguish error causes precisely. Libraries often define their own error types to allow callers to react differently depending on the error.

Connections

Exception handling in other languages

Contrast with Go's explicit error returns

Understanding Go's approach clarifies why explicit checks improve code clarity compared to hidden exceptions.

Functional programming's Either/Result types

Similar pattern of returning success or failure values

Knowing Go errors as values connects to functional patterns that avoid exceptions by encoding errors in return types.

Human decision-making under uncertainty

Handling errors is like checking for problems before acting

Recognizing errors explicitly mirrors how people assess risks and decide carefully, improving reliability.

Common Pitfalls

#1 Ignoring the error return value

Wrong approach:

result, _ := divide(10, 0)
fmt.Println("Result:", result)

Correct approach:

result, err := divide(10, 0)
if err != nil {
fmt.Println("Error:", err)
return
}
fmt.Println("Result:", result)

Root cause:

Misunderstanding that errors must be checked explicitly leads to ignoring them and using invalid results.

#2 Comparing error messages as strings

Wrong approach:

if err.Error() == "not found" {
// handle error
}

Correct approach:

if errors.Is(err, ErrNotFound) {
// handle error
}

Root cause:

Treating error messages as identifiers is fragile and breaks if messages change.

#3 Returning nil error but invalid data

Wrong approach:

func divide(a, b int) (int, error) {
if b == 0 {
return 0, nil
}
return a / b, nil
}

Correct approach:

func divide(a, b int) (int, error) {
if b == 0 {
return 0, errors.New("cannot divide by zero")
}
return a / b, nil
}

Root cause:

Confusing no error with invalid operation causes silent failures.

Key Takeaways

In Go, errors are normal values returned by functions that must be checked explicitly to keep programs reliable.

Ignoring errors or treating them like exceptions leads to fragile and unpredictable code.

Custom error messages and wrapping provide detailed context that helps debugging and maintenance.

Using sentinel and typed errors allows precise error handling beyond simple message checks.

Understanding Go's error handling design helps write clear, robust, and maintainable software.