How to Effectively Handle Errors Across Multiple Abstraction Levels in Go?

How to Effectively Handle Errors Across Multiple Abstraction Levels in Go

Handling errors gracefully and consistently is crucial for maintaining the health and reliability of large and complex Go applications. However, when working with multiple layers of abstraction, it becomes a challenge to manage errors effectively while avoiding duplicate logging or losing important context.

Annotating Errors for Contextual Propagation

A powerful technique for error handling across abstraction levels is error annotation. This approach involves creating a new error value and wrapping the original error within it, providing additional context and information about the error's origin.

To implement error annotation, you can use a library like github.com/pkg/errors. It offers functions for wrapping errors (errors.Wrap()) and extracting wrapped errors (errors.Cause()).

Here's an example demonstrating error annotation:

func (o *ObjectOne) CheckValue() error {
    if o.someValue == 0 {
        return errors.New("Object1 illegal state: value is 0")
    }
    return nil
}

func (oT *ObjectTwoHigherLevel) CheckObjectOneIsReady() error {
    if err := oT.objectOne.CheckValue(); err != nil {
        return errors.Wrap(err, "Object2 illegal state: Object1 is invalid")
    }
    return nil
}

func (oTh *ObjectThreeHiggerLevel) CheckObjectTwoIsReady() error {
    if err := oTh.ObjectTwoHigherLevel.CheckObjectOneIsReady(); err != nil {
        return errors.Wrap(err, "Object3 illegal state: Object2 is invalid")
    }
    return nil
}

If a user of ObjectThreeHiggerLevel decides to handle the error, they will receive a comprehensive error message that traces the error through all the abstraction levels, preserving the original context.

o3 := &ObjectThreeHiggerLevel{}
if err := o3.CheckObjectTwoIsReady(); err != nil {
    fmt.Println(err)
}

Output:

Object3 illegal state: Object2 is invalid: Object2 illegal state: Object1 is invalid: Object1 illegal state: value is 0

Extending Errors for Simplified Propagation

If you prefer a simpler approach, you can also "extend" errors by using fmt.Errorf() to create a more descriptive error message. This method is less flexible than annotation but still allows for some contextual information to be added.

Example using fmt.Errorf():

func (o *ObjectOne) CheckValue() error {
    if o.someValue == 0 {
        return fmt.Errorf("Object1 illegal state: value is %d", o.someValue)
    }
    return nil
}

func (oT *ObjectTwoHigherLevel) CheckObjectOneIsReady() error {
    if err := oT.objectOne.CheckValue(); err != nil {
        return fmt.Errorf("Object2 illegal state: %v", err)
    }
    return nil
}

func (oTh *ObjectThreeHiggerLevel) CheckObjectTwoIsReady() error {
    if err := oTh.ObjectTwoHigherLevel.CheckObjectOneIsReady(); err != nil {
        return fmt.Errorf("Object3 illegal state: %v", err)
    }
    return nil
}

Error message when handling in ObjectThreeHiggerLevel:

Object3 illegal state: Object2 illegal state: Object1 illegal state: value is 0

By employing either error annotation or extension, you can effectively handle errors at different abstraction levels, avoid duplicate logging, and ensure that all relevant context is preserved for error investigation and resolution.

The above is the detailed content of How to Effectively Handle Errors Across Multiple Abstraction Levels in Go?. For more information, please follow other related articles on the PHP Chinese website!