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!
Top comments (2)
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
Wrapperinterface, while it's not possible to wrap more than one and only one specific error solely withfmt.Errorf().You show how that is done with custom errors that have the
Unwrapmethod, 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
[]errororSomeCustomError, the Golang guidelines recommend to always declare a simpleerroras return values, which by virtue of being a chain are still able to convey multiple separate events if the caller wants to dig deeper withIsandAs.In practice, for clarity, the following does not appear to be possible at the moment using exclusively
fmt.Errorf().Given two simple errors:
I cannot find any way to create an
err3exclusively withfmt.Errorf()such that both of the following statements are true: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-inerrortype 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.
this is so true, man. Is there a way to do this now?