4 ms·
If there are multiples `try` inside a single function, and we are debugging and want to know which call raises error, how can we do that? Should `try` wraps th
by stepforward 7y ago
If there are multiples `try` inside a single function, and we are debugging and want to know which call raises error, how can we do that?
Should `try` wraps the error and adds something more useful for debugging purpose? (the line number probably?)
- ithkuil 7y agoYeah, 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) } }
- grey-area 7y agoMaybe don't use this try if you want more detailed info on specific errors? It's for using where you would use if != nil return err not in every instance. If you try to use it everywhere it won't work well.