When working with Go, proper error handling is crucial for writing robust applications. Today, we’ll explore an interesting pattern involving deferred functions and named return values, specifically in the context of handling multiple potential error sources.

The Problem

Consider a common scenario: you need to read a request body and ensure it’s properly closed afterward. You want to capture both any read errors and any close errors. Here’s what many developers might write initially:

func body(r *http.Request) ([]byte, error) {
    b, err := io.ReadAll(r.Body)
    defer r.Body.Close()  // Potential error ignored!
    return b, err
}

This code has a subtle issue: we’re ignoring any error that might occur when closing the body. While Close() errors are often less critical than read errors, they can indicate resource leaks or other problems that we should at least be aware of.

A Better Solution

Here’s an improved version that captures both types of errors:

func body(r *http.Request) (bod []byte, err error) {
    b, err := io.ReadAll(r.Body)
    if err != nil {
        return nil, err
    }

    defer func(b io.ReadCloser) {
        if b == nil {
            return
        }
        err = errors.Join(err, b.Close())
    }(r.Body)

    return b, err
}

Let’s break down why this works and what’s happening behind the scenes.

Understanding the Magic

Several key Go concepts come together to make this work:

1. Named Return Values

The function signature uses named return values: (bod []byte, err error). This creates variables that are initialized to their zero values at function start and can be accessed throughout the function, including in deferred functions.

2. Defer Execution Order

Deferred functions execute after the return statement is evaluated but before the function returns to its caller. This means:

  1. The return values are evaluated
  2. Deferred functions execute in LIFO order
  3. The function returns to its caller

3. Variable Capture vs Shadowing

When we write:

b, err := io.ReadAll(r.Body)

This isn’t creating a new err variable - it’s assigning to our named return parameter. The := operator only creates new variables for names that haven’t been declared in the current scope.

Behavior Analysis

Let’s examine what happens in different scenarios:

Scenario 1: Everything Succeeds

- ReadAll succeeds (err = nil)
- Close succeeds (Close() returns nil)
- Final result: err = nil

Scenario 2: ReadAll Fails

- ReadAll fails (err = ReadAll error)
- Function returns early with ReadAll error
- Close still happens via defer
- Final result: err = joined errors (if Close also failed)

Scenario 3: Only Close Fails

- ReadAll succeeds (err = nil)
- Close fails
- Final result: err = Close error

Alternative Approaches

Sometimes you might want more control over error handling. Here’s an alternative approach that handles errors more explicitly:

func body(r *http.Request) ([]byte, error) {
    b, readErr := io.ReadAll(r.Body)
    if readErr != nil {
        r.Body.Close() // Best effort close
        return nil, readErr
    }

    if closeErr := r.Body.Close(); closeErr != nil {
        return b, closeErr
    }

    return b, nil
}

This version gives you more control but loses some of the elegance of using defer for cleanup.

Best Practices

  1. Use named return values when you need to modify return values in deferred functions
  2. Be conscious of error priority - sometimes you want to preserve the original error
  3. Consider using errors.Join when both errors are meaningful
  4. Document your error handling strategy, especially when using defer

Conclusion

Go’s defer mechanism, combined with named return values and error joining, provides a powerful way to handle multiple error sources. While it might seem magical at first, understanding how these pieces work together helps us write more robust code.

The pattern we explored today is particularly useful when dealing with resources that need cleanup, like file handles, network connections, or database transactions. Just remember that with great power comes great responsibility - make sure your error handling strategy is clear and well-documented.

Happy coding!