Acceptable Golang idiomatic nested error handling?

One of the Go Prover is:

Don’t just check errors, handle them gracefully

I recommend you to read this post from Dave Cheney

I put the highlights here:

"There is no single way to handle errors. Instead, I believe Go’s error handling can be classified into the three core strategies"

  • Sentinel errors:

if err == ErrSomething { … }

"Using sentinel values is the least flexible error handling strategy, as the caller must compare the result to predeclared value using the equality operator. This presents a problem when you want to provide more context, as returning a different error would will break the equality check."

  • Error types

if err, ok := err.(SomeType); ok { … }

"An error type is a type that you create that implements the error interface. "

  • Opaque errors

x, err := bar.Foo() if err != nil { return err } // use x

"I call this style opaque error handling, because while you know an error occurred, you don’t have the ability to see inside the error. As the caller, all you know about the result of the operation is that it worked, or it didn’t."

.... read all the post.

I think the important aspect of error handling is to Don’t just check errors, handle them gracefully, I hope this can help you.

Tags:

Idioms

Go