Should warnings and other signals usually have a class? (And if so, what class name is suggested?) #172
Comments
|
I don't think we're ready to commit to a public statement on this yet (because we're still figuring it out ourselves), but in general I don't think it's worthwhile to class a condition until you've extracted it out into its own function, because you've needed it in multiple places. In general I start with the package name (since it's an S3 class) and then a descriptive phrase — I don't typically worry about distinguishing between errors, warnings, and messages (mostly because I've never bothered classing a warning or message). You can see some recent examples at https://github.com/rstudio/pins/blob/master/R/testthat.R#L127-L143. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In sfirke/janitor#452, a discussion of suppressing a specific warning came up. I know that
rlang::warn()provides the simple ability to have classed warnings, and I think that for localization support among other reasons, it is likely best practice to give all signals (messages, warnings, and errors) a class to enable easier handling.I looked into the style guide (https://style.tidyverse.org/error-messages.html), and I didn't see a suggestion for classing signals. I think that classing signals should be suggested in the guide. And, if suggested, I think it would help to suggest a class name structure to help give specificity and lack of intersection between class names.
My thought in the janitor issue is the class could be named something like a concatenation of:
That should keep it fully specific with effectively zero chance of two signals having overlapping classes. But, it is a pretty long class name.
The text was updated successfully, but these errors were encountered: