Support for errors.Unwrap()

[crussell52]

Is your feature request related to a problem? Please describe.

The idiom of wrapping errors within other errors was introduced in go 1.13 and is currently preferred idiom. This effectively allows for a chain of errors. Currently there is no apparent (library-provided) way to show that chain.

Describe the solution you'd like
Have a built-in way to unwrap errors when they are logged.

Describe alternatives you've considered
Creating a custom Field - but these seems odd to do for a language-promoted idiom.

Is this a breaking change?
The encoder for the existing ErrorType could handle this transparently.

That wouldn't break the API but it might be surprising to users that they get a different encoding for the same errors all of a sudden. For the sake of "least surprise", it's probably appropriate to introduce a new field type (WrappedErrorType?) that encodes in this fashion.

Additional context
Go blog: Working with Errors in Go 1.13

[rabbbit]

I'm not related to zap development, but out of personal curiosity - what would your expected output be?

Currently, I think zap supports wrapped errors just fine: fmt.Errorf("did this: %w", errors.New("this failed")) prints out did this: this failed, right? What would you expect instead?

[crussell52]

@rabbbit Thanks for the feedback... did you read the referenced blog post, by chance? It addresses the difference between the idiom you posted (fmt.Errorf(...)) and implementing the Unwrap() method -- and the advantages of the latter.

Your question of "how should it look", is a good one, nonetheless... I'm not sure I'm experienced enough in effective go logging to get too detailed about it (as compared to the experience level of the project maintainers). But I think I would like to see the error type name and error message of each wrapped error in the chain.

Extracting type name might be considered too expensive for Zap's goals, but it would be useful when searching logs for occurrences of a particular error type in contrast to searching for message keywords. The latter (error messages) are more likely to be changed by developers without realizing the external impact (e.g. tools or monitors designed to detect certain errors).