You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
hard to improve: we can easy improve perf like this in central point
So, rather than forcing the caller to manually annotate each stack frame in the return path, we need a errors that can just record the entire stack trace at the point that an error is created by the errors package.
Why
Now, we are using
juju/errors
to handle go error, but in these days we find some questions related it(#7114, #7120), let us rethink about it.Go though the surface question, the question make me confuse is Why we should call
errors.Trace
for every method call?After learn juju, I found that we call
errors.Trace
every call, just solve the question that save call stack in error.I don't feel it's NOT a good choose to do that:
if err != nil {return errors.Trace(err)}
again and againSetLocation
make heavyruntime.Caller
in every level method?builder pattern
, error retun in finalbuild()
method is naturally, but due to juju we cannot. and we have see many code review comment to remind misserrors.Trace
callSo, rather than forcing the caller to manually annotate each stack frame in the return path, we need a errors that can just record the entire stack trace at the point that an error is created by the errors package.
After search, https://github.com/pkg/errors is what we hoped, and author meet the same question and move from manual trace way to new error save stack way, too~
Perf
just write a simple demo to test two way.
result:
cpu-perf for juju all error:
cpu-perf for pkg all error:
TODO
errors.Trace
callCan we do this?~
The text was updated successfully, but these errors were encountered: