3 ms·
Yeah, that was my first thought as well. I'm using the juju/errors library "return errors.Trace(err)", which annotates the error with the line number of the ret
by ithkuil 7y ago
Yeah, that was my first thought as well. I'm using the juju/errors library "return errors.Trace(err)", which annotates the error with the line number of the return.
That wouldn't work in a deferred function.
Perhaps the compiler could make that possible somehow although I suspect that might conflict with the stated goal of improving the efficiency of defer due to "try" encouraging more people to use it.
- akavel 7y agoA deferred function is called at the line where return would happen, so you can still access stack trace information required for errors.Trace(err) from inside a deferred function. You just need to go "one frame higher". (See the stack trace printed in: https://play.golang.org/p/Bpqdm8oWBF3 https://play.golang.org/p/Bpqdm8oWBF3). As a result, I believe juju/errors could then be extended with a new function, to be used like this: func foobar(...) (..., err error) { defer errors.Tracify(&err) ... } where: package juju/errors func Tracify(err *error) { if *err != nil { *err = TraceFromDefer(*err) } }