Hi, thank you for the work you've done on this library!
I noticed that your code is used in some other projects. What would you think about adding some context before calling log.Fatalln ? For example, sometimes, the code just stops executing because an api key is not provided, as in this line. For users of this package, maybe it would be more useful, if the errors package would be integrated? The following snippet gives a nice example of providing a stack trace:
type stackTracer interface {
StackTrace() errors.StackTrace
}
err, ok := errors.Cause(fn()).(stackTracer)
if !ok {
panic("oops, err does not implement stackTracer")
}
st := err.StackTrace()
fmt.Printf("%+v", st[0:2]) // top two frames
// Example output:
// github.com/pkg/errors_test.fn
// /home/dfc/src/github.com/pkg/errors/example_test.go:47
// github.com/pkg/errors_test.Example_stackTrace
// /home/dfc/src/github.com/pkg/errors/example_test.go:127
I debugged some code unexpectedly stopping with a message saying that the api key was not provided, and after bisecting the code, I identified the above mentioned log.Fatalln. Alternatively, perhaps making the setKey part of a constructor that returns an err as well?
Hi, thank you for the work you've done on this library!
I noticed that your code is used in some other projects. What would you think about adding some context before calling
log.Fatalln
? For example, sometimes, the code just stops executing because an api key is not provided, as in this line. For users of this package, maybe it would be more useful, if the errors package would be integrated? The following snippet gives a nice example of providing a stack trace:I debugged some code unexpectedly stopping with a message saying that the api key was not provided, and after bisecting the code, I identified the above mentioned
log.Fatalln
. Alternatively, perhaps making the setKey part of a constructor that returns anerr
as well?Thanks!