Skip to content

Conversation

@SuperQ
Copy link
Member

@SuperQ SuperQ commented Feb 9, 2021

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 superq@gmail.com

@beorn7
Copy link
Member

beorn7 commented Feb 9, 2021

I guess with go1.16 on the horizon, we can do this now.

Copy link
Member

@beorn7 beorn7 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I sense a somewhat inconsistent use of %s vs %q. Before adding a million comments, perhaps you should first tell us what the intention is.

@SuperQ SuperQ force-pushed the superq/error_is branch 2 times, most recently from f048905 to 2b31529 Compare February 9, 2021 16:46
@SuperQ
Copy link
Member Author

SuperQ commented Feb 9, 2021

Updated with some s/%s/%q.

@beorn7
Copy link
Member

beorn7 commented Feb 9, 2021

So the guideline is to quote if in doubt? I'll make a pass following that guideline.

Copy link
Member

@beorn7 beorn7 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@beorn7
Copy link
Member

beorn7 commented Feb 9, 2021

And to be clear: I have reviewed now with the assumption that we only ever want to use %s on strings where we can be certain they don't contain "weird stuff".

@SuperQ
Copy link
Member Author

SuperQ commented Feb 9, 2021

@beorn7 Yes, that seems like a reasonable policy, thanks for the great reviewing.

@SuperQ SuperQ force-pushed the superq/error_is branch 3 times, most recently from b825ab5 to 346f28a Compare February 9, 2021 22:14
Copy link
Member

@discordianfish discordianfish left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome!

@SuperQ
Copy link
Member Author

SuperQ commented Feb 10, 2021

@beorn7 Ok, I think I've got it cleaned up. PTAL.

Copy link
Member

@beorn7 beorn7 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found a few more. 🦆

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 <superq@gmail.com>
Copy link
Member

@beorn7 beorn7 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

\o/ The world is a better place now!

@SuperQ SuperQ merged commit e971af5 into master Feb 10, 2021
@SuperQ SuperQ deleted the superq/error_is branch February 10, 2021 15:13
remijouannet pushed a commit to remijouannet/procfs that referenced this pull request Oct 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants