-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fmt: Shouldn't %q (and %s) treat nil as a valid value? #39886
Comments
CC @robpike |
I'm not convinced either way. It seems odd to me that a correct output from %q would not include quotes, but It may be wisest to do nothing for most types and do something special only for the error type, where people are used to seeing nil in test output and such. But it's a fiddly thing to do. |
As for the work, wouldn't it suffice to add |
I've also run into this issue in the past, and my initial suspicion was that was an issue in I instead modified the code to use %v in cases where the error might be nil, and reserved my use of %s (or %q) to cases where I've checked that it's not. |
@robpike The catch is that since |
I'm not opposed to this change, and I'm also not enthusiastically in favor. My main concern at this point is the effect it will have on tests, as it could change golden output. It might be more disruptive than it's worth, but we can try it in the cycle if you like. As stated above, it's very easy to do. The challenge lies elsewhere. |
@ianlancetaylor The package knows it's an error as it needs to check for the Error method, so it could be done there. But it's simpler and easier to explain if the change, should it happen, is done at the top of printArg. |
@robpike I may be missing something but I think that in this case there is no way that the fmt functions can tell that the value was originally an |
@ianlancetaylor I see what you mean. Let's make the conversation more confusing: https://play.golang.org/p/pVnlOIX1ArU In any case, as I said most recently, it's probably best to do this for all types in printArg if we do it at all. I'd like some discussion about that, though, because it might be disruptive. |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
https://play.golang.org/p/YVE8n6N0xUT
What did you expect to see?
What did you see instead?
What's the rationale?
It's often useful to print
error
values enclosed with quotes in test failures:but
%q
(as well as%s
) treats anil
value as a format error and prints%!q(<nil>)
instead of plain<nil>
.Writing
\"%v\"
instead of%q
avoids the ugly error output, but it doesn't handle escaping well, and it's not desirable to have even"<nil>"
enclosed with quotes.This leaves the plain
%v
as the only easy option (unless you are willing to have anotherif
).Wouldn't it be nice to have
%q
(and%s
by extension) print just<nil>
, as with%v
, if the argument isnil
?%q
and%s
already handle anerror
argument as a string (through theError
method) if the argument is notnil
, but having an error output for anil
argument limits its usefulness.The text was updated successfully, but these errors were encountered: