Closed ddsjoberg closed 4 months ago
Package | Line Rate | Health |
---|---|---|
admiral | 98% | ✔ |
Summary | 98% (4717 / 4811) | ✔ |
Should the
class
argument be specified in thecli_abort()
calls?
How would we name the classes, could use function name, but what if there is more than one check in the function. Would we ever use the class? I can see benefit of having class in assertion functions, so we can just check if check is triggered without checking message. But not sure we would use the class?
Should the
class
argument be specified in thecli_abort()
calls?How would we name the classes, could use function name, but what if there is more than one check in the function. Would we ever use the class? I can see benefit of having class in assertion functions, so we can just check if check is triggered without checking message. But not sure we would use the class?
Good questions!
The use case I had in mind was where you have a company or study specific function which calls an admiral function and you want to catch the error to provide a more user-friendly error message. However, with a class you could easily catch the error but for the message you still need to parse the original message to get out what went wrong and generate the new message. We have this problem even with our assert_*()
functions. In assert_terms()
I had to call assert_data_frame()
twice (once for checking it's a data frame and again for checking if the required variables are present) to be able to update the error message.
Maybe it does not help much to set the class with our current approach.
I have added the changes suggested by @kaz462 to https://github.com/pharmaverse/admiral/pull/2417.
Should we cancel this PR as the changes are included also in https://github.com/pharmaverse/admiral/pull/2417?
I have added the changes suggested by @kaz462 to #2417.
Should we cancel this PR as the changes are included also in #2417?
Yes lets cancel this one - it is getting a little messy.
@bundfussr do you mind closing as you are close to this process
There are a lot of calls to
rlang::abort()
that need updating. Best to tackle this in parts.Thank you for your Pull Request! We have developed this task checklist from the Development Process Guide to help with the final steps of the process. Completing the below tasks helps to ensure our reviewers can maximize their time on your code as well as making sure the admiral codebase remains robust and consistent.
Please check off each taskbox as an acknowledgment that you completed the task or check off that it is not relevant to your Pull Request. This checklist is part of the Github Action workflows and the Pull Request will not be merged into the
main
branch until you have checked off each task.styler::style_file()
to style R and Rmd filesinst/cheatsheet/admiral_cheatsheet.pptx
and re-upload a PDF version of it to the same folder.devtools::document()
so all.Rd
files in theman
folder and theNAMESPACE
file in the project root are updated appropriatelyNEWS.md
under the header# admiral (development version)
if the changes pertain to a user-facing function (i.e. it has an@export
tag) or documentation aimed at users (rather than developers)pkgdown::build_site()
and check that all affected examples are displayed correctly and that all new functions occur on the "Reference" page.lintr::lint_package()
R CMD check
locally and address all errors and warnings -devtools::check()