Support for obtaining a stack trace without requiring github.com/pkg/errors

まず、パッケージで現在使用されている github.com/pkg/errors とスタックトレースへのアクセス箇所を特定します。既存の動作を、提案されている StackTrace() []uintptr インターフェースおよび代替の Callers() []uintptr インターフェースと比較します。異なるパッケージのエラーが github.com/pkg/errors を必要とせずにスタックトレースを公開または保持でき、互換性に関する期待事項が解決されれば完了です。

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.)