Consider StackTrace() []uintptr

[cep21]

Hi,

I am trying to write a library to interoperate with wrapped errors.

There are many error wrapping libraries, but I can only get the StackTrace() of this one by importing this one. This creates problems trying to write library agnostic code.

With Cause() error, I can simulate an error exposing this interface inside my library, meaning I can interoperate with pkg/errors without needing to import it, as well as define an API that other libraries can implement without forcing them into pkg/errors API.

With StackTrace() StackTrace I am forced to tell people wanting to work with my library to import errors, just for the StackTrace object, just to wrap their own stack trace with it.

This is a general problem with APIs that don't use Go's core types as parameters. Since a stack trace is just an array of pointers, if the implementation was StackTrace() []uintptr, then other error wrapping libraries could standardize to this and we could all interoperate.

I would also say that pretty printing a stack trace is behavior reasonably independent of wrapping errors itself. By returning the stack trace raw, you allow libraries to choose how it should be pretty printed: with maybe errors package providing a default implementation like it does now.

[davecheney]

Id love to do that, that was how it worked previously, but if the type is
unnamed then it cannot host a Formatter method.

On Fri, 5 Aug 2016, 03:44 Jack Lindamood notifications@github.com wrote:

Hi,

I am trying to write a library to interoperate with wrapped errors.

There are many error wrapping libraries, but I can only get the
StackTrace() of this one by importing this one. This creates problems
trying to write library agnostic code.

With Cause() error, I can simulate an error exposing this interface
inside my library, meaning I can interoperate with pkg/errors without
needing to import it, as well as define an API that other libraries can
implement without forcing them into pkg/errors API.

With StackTrace() StackTrace I am forced to tell people wanting to work
with my library to import errors, just for the StackTrace object, just to
wrap their own stack trace with it.

This is a general problem with APIs that don't use Go's core types as
parameters. Since a stack trace is just an array of pointers, if the
implementation was StackTrace() []uintptr, then other error wrapping
libraries could standardize to this and we could all interoperate.

I would also say that pretty printing a stack trace is behavior reasonably
independent of wrapping errors itself. By returning the stack trace raw,
you allow libraries to choose how it should be pretty printed: with maybe
errors package providing a default implementation like it does now.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#79, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAcA0RhUzhUTAoiIG08AMZ1FSjaHZL9ks5qciT_gaJpZM4Jc8o4
.

[cep21]

Why can't the error type have a Stack() []uintptr function, error type have a Formatter method, and there be helpers to format []uintptr stacks that error uses in its Formatter method? There's even already precedent in the stdlib for Stack() []uintptr in the runtime package.

[davecheney]

Maybe it can change, I haven't looked closely. It depends if people want to
do st := err.Stack(); fmt.Printf("%+v", st); or if they want to
fmt.Printf("%+v", err)

On Fri, Aug 5, 2016 at 1:37 PM, Jack Lindamood notifications@github.com
wrote:

Why can't the error type have a Stack() []uintptr function, error type
have a Formatter method, and there be helpers to format []uintptr stacks
that error uses in its Formatter method? There's even already precedent in
the stdlib for Stack() []uintptr in the runtime package.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#79 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA9O_yUd1GqHtH033rnNIfY-5BEytks5qcrAJgaJpZM4Jc8o4
.

[cep21]

Can't you make fmt.Printf("%+v", err) work like it does today by having func (e _error) Format format the []uintptr returned by e.Stack() ? Maybe i'm missing something:

func (e _error) Format(s fmt.State, verb rune) {
    switch verb {
    case 'v':
        if s.Flag('+') {
            io.WriteString(s, e.msg) 
            fmt.Fprintf(s, builtInFormatting(e.Stack())
            return
        }
        fallthrough
    case 's':
        io.WriteString(s, e.msg)
    }
}

[cep21]

I think I see what you mean now. I don't think it's too much to, if someone wants to format the stack only, to get it out as an []uintptr and call some string formatter on that. There are probably many ways someone may want to format a []uintptr. Maybe errors.Stack() is one way.

[mark-adams]

Maybe I'm missing something but... why not both? Is there reason why the package couldn't support both StackTrace() StackTrace and Stack() []uintptr?

I'd like to add support to raven-go, Sentry's library for capturing and reporting errors in Go programs, but accessing the stack trace from pkg/errors is also a hang-up for me.

@davecheney If you're open to this, I can easily submit a PR.

[fgblomqvist]

Was there ever a decision made about this? I'm in the same camp as cep21 and mark-adams, I think it would be valuable to have a universal API, and if you wanna keep the formatting methods, keep the current API as well (what mark-adams suggested).