Update error message handling #357
Conversation
SuperQ
force-pushed
the
superq/error_is
branch
from
d7ba833 to
ac44f90
Compare
|
I guess with go1.16 on the horizon, we can do this now. |
SuperQ
force-pushed
the
superq/error_is
branch
2 times, most recently
from
f048905 to
2b31529
Compare
|
Updated with some |
|
So the guideline is to quote if in doubt? I'll make a pass following that guideline. |
There was a problem hiding this comment.
OK, I have found a number of more instances that I believe should be %q.
In summary, I wholeheartedly agree that potentially unknown or misformatted strings in the middle of an error message should be quoted. I'm way more relaxed about anything after a colon, after which you only have a blank and then said string. But I can see the argument for using %q there, too, especially if the string might contain line breaks or tabs.
|
And to be clear: I have reviewed now with the assumption that we only ever want to use |
|
@beorn7 Yes, that seems like a reasonable policy, thanks for the great reviewing. |
SuperQ
force-pushed
the
superq/error_is
branch
3 times, most recently
from
b825ab5 to
346f28a
Compare
|
@beorn7 Ok, I think I've got it cleaned up. PTAL. |
Use Go 1.13 `%w` error formatting
* Update minimum Go version to 1.13.
* Bump vendoring.
* Update all error format strings to use %w.
* Cleanup consistency of use.
* Cleanup use of `errors.New("string" + var)` to use `fmt.Errorf()`.
#310
Signed-off-by: Ben Kochie <[email protected]>
SuperQ
force-pushed
the
superq/error_is
branch
from
346f28a to
67a72b2
Compare
Update error message handling
Use Go 1.13
%werror formattingerrors.New("string" + var)to usefmt.Errorf().#310
Signed-off-by: Ben Kochie [email protected]