cockroachdb / cockroachdb/errors
Support for obtaining a stack trace without requiring github.com/pkg/errors
- Linguagem predominante
- Go
- Estrelas
- 2.5k
- Forks
- 74
- Métricas de merge de PRs
- Nenhum PR com merge em 30d
Descrição
I made [a spiritual successor of `github.com/pkg/errors`](https://gitlab.com/tozd/go/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](https://github.com/go-errors/errors):
```
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.)
Guia de contribuição
Nenhum guia de contribuição indexado para este repositório
Avaliação
Esta issue ainda não foi avaliada.