FastGenWithCause() and GenWithStackByCause() should not take arguments #86
Description
These two methods are currently used in two ways,
-
The correct way, calling it on a wrapped error e.g. https://github.com/tikv/pd/blob/09feb815ce7124b7a67ed6357370b45f03c34960/pkg/tso/allocator_manager.go#L366
return errs.ErrEtcdTxnInternal.Wrap(err).GenWithStackByCause()
-
The wrong way, calling it directly on an error template, filling in with arguments, e.g. https://github.com/tikv/pd/blob/09feb815ce7124b7a67ed6357370b45f03c34960/pkg/election/lease.go#L63
return errs.ErrEtcdGrantLease.GenWithStackByCause("lease is nil")
We are going to reject the wrong way by requiring two methods accept no arguments. You should use these existing, correct methods instead:
| Wrong usage | Correct usage |
|---|---|
e.GenWithStackByCause(args...) |
e.GenWithStackByArgs(args...) |
e.FastGenWithCause(args...) |
e.FastGenByArgs(args...) |
The problem of supporting the wrong way is this forces us to allow e.Wrap(innerErr).FastGenWithCause(args...) which leads to an error in this form:
e.message = e.cause.Error() // e.cause == innerErr
e.args = argsthe existence of e.args means e.message is treated as a format-string input, but innerErr.Error() typically is already formatted, so the resulting error message would be wrong.
Activity