Error Chains in Go 1.13

Go added a neat feature in 1.13 that they call error chains

Errors can now implement a method called Unwrap that should return another error. Typically, this is an error that occurred further down in the call stack.

It is very common in go to have errors get tossed further and further back up the call stack as functions resolve, until its finally handled properly. Error chains allow you to carry a series of errors all the way back up the call stack more easily.

They added two new functions in the errors package to interact with this concept, Is and As

Is takes a argument of an error and another error, returns true if any instance of the second error occurs in the first error's chain, and false otherwise.

As takes the same arguments, but sets the value of the second argument equal to the error that was found in the first error's chain if it was present.

Check out the video to see the concept in action.

If you liked it and want to know when I post more, be sure to subscribe and thank ya'll again for your time!

Comments

[B.E.]

This is a very good presentation of the feature, thank you Donald!

I would also add that unfortunately the only way to create a chain seems to be through the use of custom error types that implement the Wrapper interface, while it's not possible to wrap more than one and only one specific error solely with fmt.Errorf().

You show how that is done with custom errors that have the Unwrap method, which is great, but it's important to specify that it's the only method to create chains.

It's also interesting to offer a concrete scenario where we might need chains. You mention deep callstacks, which is true. One other way I use chained errors is to have "markers" of specific events when multiple non-fatal errors can occur in a single call.

Instead of returning explicitly, say, an []error or SomeCustomError, the Golang guidelines recommend to always declare a simple error as return values, which by virtue of being a chain are still able to convey multiple separate events if the caller wants to dig deeper with Is and As.

In practice, for clarity, the following does not appear to be possible at the moment using exclusively fmt.Errorf().

Given two simple errors:

err1 := errors.New("first error")
err2 := errors.New("second error")

I cannot find any way to create an err3 exclusively with fmt.Errorf() such that both of the following statements are true:

errors.Is(err3, err1)
errors.Is(err3, err2)

This is unfortunate to say the least. One would have hoped that when the Go Team introduced errors.Is(), errors.As() and "%w" they would also give the built-in error type the ability to create chains, or that they would provide some utility function to that effect.

Maybe they didn't because of the non-breaking promise, but still it's inconvenient and as a result native error wrapping is vastly underused.

[Huy Le]

this is so true, man. Is there a way to do this now?