Support pkg/errors Stacktracer interface

[akshayjshah]

Consider whether we should take on a third-party dependency to support pkg/errors. If we really think that this package is garnering widespread adoption, we should support its error type and include both stacktraces and causes in log output.

Thoughts, @prashantv and @jcorbin?

[jcorbin]

I'm generally +1 on supporting anything that's "almost" cannon; for me that heuristic looks like:

• golang.org
• not golang.org/x

In particular, I think the case of errors' Stacktracer a good fit.

[prashantv]

What kind of support were you thinking? Logging a separate field like "errorStackTrace" with the stack trace?

I'd prefer not to take a dependency on pkg/errors, especially since it doesn't seem like the most popular third-party errors package yet,
https://godoc.org/?q=errors

It's unfortunate that we can't check whether there's a stacktrace we can log without depending on the package. There are discussions around changing this (pkg/errors#79). I think we should wait till there's a 1.0 tagged before taking on the dependency.

There's one "trick" to getting stack traces in logs if we really want -- instead of calling err.Error(), we could do fmt.Sprintf("%+v", err) which will include the stack trace. I don't think we want to do that by default though, but there could be an ErrorVerbose or some other field to do that.

[akshayjshah]

%+v might be a nice middle ground. Unfortunately, it won't work in zap.Any (or in the SugaredLogger) unless we take a dependency on pkg/errors, since we'll need to make an interface cast. Might be best to first open a PR to fix that issue, see if it's accepted, and hope that we'll be able to support them without a source dependency.

[akshayjshah]

Actually, it looks like we can just cast into the fmt.Formatter interface - this has the added virtue of working with a few other error-wrapping packages. Yay!