Helper function for retrieving root stack trace from error

[creasty]

Why

1. Want to retrieve function name, file and line separately.
   For now, the simplest way to do so is by using Formatter as follows.

   for _, f := range err.StackTrace() {
     file := fmt.Sprintf("%s", f)
     line, _ := strconv.ParseInt(fmt.Sprintf("%d", f), 10, 32)
     funcName := fmt.Sprintf("%n", f)
     fmt.Printf("%s at %s:%d\n", funcName, file, line)
   }

2. These is no mechanism for extracting the root stack trace -- the longest stack trace.

Use case

Most feasible use case is an integration with error reporting systems such as honeybadger.

https://github.com/honeybadger-io/honeybadger-go/blob/f37170201ccce33edcb44f976565698c5aeb7fc4/error.go#L13-L17

type Frame struct {
	Number string `json:"number"`
	File   string `json:"file"`
	Method string `json:"method"`
}

What

Create a helper function errors.Trace which behaves like errors.Cause and returns the underlying stack trace ([]Frame) of the error.

package main

import (
	built_in_errors "errors"
	"fmt"

	"github.com/pkg/errors"
)

func foo() error {
	return built_in_errors.New("foo")
}

func bar() error {
	return errors.Wrap(foo(), "foo in bar")
}

func baz() error {
	return errors.Wrap(bar(), "bar in baz")
}

func main() {
	err := errors.Wrap(baz(), "baz in main")

	if frames := errors.Trace(err); frames != nil {
		for _, f := range frames {
			fmt.Printf("%s at %s:%d\n", f.Name(), f.File(), f.Line())
		}
	}
}

$ go run main.go
bar at /Users/ykiwng/Desktop/main.go:15
baz at /Users/ykiwng/Desktop/main.go:19
main at /Users/ykiwng/Desktop/main.go:23
main at /usr/local/Cellar/go/1.7.3/libexec/src/runtime/proc.go:183
goexit at /usr/local/Cellar/go/1.7.3/libexec/src/runtime/asm_amd64.s:2086

[martinheidegger]

This would also help to implement stack traces in sentry: getsentry/raven-go#88

[davecheney]

Please open an issue to discuss your design before sending and implantation. Thank you.

…

On 18 Apr 2017, at 12:35, Martin Heidegger ***@***.***> wrote: This would also help to implement stack traces in sentry: getsentry/raven-go#88 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[creasty]

Sorry, didn't read

Contributing
...
Before proposing a change, please discuss your change by raising an issue.

[davecheney]

Thank you. It is important to discuss the problem you have before proposing a solution.

…

On Tue, 18 Apr 2017, 18:07 Yuki Iwanaga ***@***.***> wrote: Sorry, didn't read Contributing ... Before proposing a change, please discuss your change by raising an issue. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#113 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAcA6M6jwbu7lMZCAAVYc0Xei43Uv4Wks5rxG8jgaJpZM4M_BJq> .

[gregwebs]

I added this functionality as GetStackTracer on our fork.

[creasty]

Actually, I've created a better solution at https://github.com/srvc/fail and stopped using pkg/errors.

c.f., Create a virtual stack trace by merging multiple stack traces
srvc/fail#13

[gregwebs]

@creasty I saw svc/fail. I really like what the package offers and particularly the idea of being able to merge stack traces. However, I am concerned about the potential for worse performance with all the stack trace creation and I am also working towards a different place in the design space by using our fork of pkg/errors as a base and building a package for error codes.