3 ms·
No word about adding proper stack traces by default? Currently, your best bet of finding where an error was actually generated, if it is returned a few times b
by tgsovlerkhgsel 8y ago
No word about adding proper stack traces by default?
Currently, your best bet of finding where an error was actually generated, if it is returned a few times before finally being logged/returned to an RPC client, is searching for fragments of the error string and hoping that a) the part that you searched for is part of the literal and not dynamically built b) it is unique c) you can guess the call path that led to this error.
Of course, in a perfect world, all error messages would be so descriptive that you could immediately find the issue just by reading the error message, but unfortunately, ideals and ideology rarely create solutions that work well in the real world.
- networkimprov 8y agoOne of the criticisms of exception handling is that it spends cycles assembling a stack trace before it knows that it's needed. Go generates a stack-trace for panic() or via runtime/debug.PrintStack(); I recommend the latter before log.Fatal().
- ben_jones 8y agoA nifty code snippet I use for this: // ErrLine returns an error formatted to include the line // number of where it occurred (presumably with a performance penalty) func ErrLine(err error) error { if err != nil { // notice that we're using 1, so it will actually log the where // the error happened, 0 = this function, we don't want that. pc, fn, line, _ := runtime.Caller(1) err = fmt.Errorf("[error] in %s[%s:%d]: %s", runtime.FuncForPC(pc).Name(), fn, line, err.Error()) } return err }
- deleted 8y ago[deleted]
- h2j24 8y agoThe errors package is really useful for generating stack traces in Go 1: https://godoc.org/github.com/pkg/errors https://godoc.org/github.com/pkg/errors