-
Notifications
You must be signed in to change notification settings - Fork 70
Description
I made a spiritual successor of github.com/pkg/errors some time ago and in it I want to know if an error already contains a stack trace. The goal is that if a large codebase uses different packages for errors, they should work together and not hide existing recorded information, like a stack trace.
One of the issues with github.com/pkg/errors is that its stackTracer interface uses a custom type only exported by github.com/pkg/errors. And it seems this package relays heavily on that and reuses it and even re-exports it.
I would suggest that instead, the following interface is implemented:
type stackTracer interface {
StackTrace() []uintptr
}
Then, it is easy to obtain a stack trace, use it, format it, and one does not have to depend on a library which created the error.
If you do want to keep using github.com/pkg/errors and re-exporting it and keeping its interface (to prevent a breaking change), I have seen also the following interface being used in this package:
type goErrorsStackTracer interface {
Callers() []uintptr
}
But given that github.com/pkg/errors is deprecated, then it is probably reasonable to drop its direct use (this package seems to use it for stack formatting as well) and just change the function to StackTrace() []uintptr.
(As I mentioned in #70, you can also use my package as drop-in maintained replacement for github.com/pkg/errors which provides same stack frame formatting features, but does not lock you in into custom types just to access a stack trace.)