[R-pkg-devel] Seeking feedback on a package before submitting to CRAN

Taras Zakharko t@r@@@z@kh@rko @end|ng |rom uzh@ch
Fri Jul 1 14:59:22 CEST 2022


Dear all, 

I have written a small lightweight utility package for R developers that implements opinionated assertion checking routines. This is mostly a drop-in replacement for base::stopifnot() but with some additional features that simplify debugging and error location. Before submitting the package on CRAN I was hoping that someone here would be so kind to have a quick look and maybe offer some feedback. The package is called "precondition" and can be found on GitHub here:

  https://github.com/tzakharko/precondition 

If you would like to leave some feedback I have created a GitHub issue just for that: 

  https://github.com/tzakharko/precondition/issues/1

Here is a quick summary as to what this package is about: it implements a thematic collection of assertion routines that check some conditions and report an informative error if the conditions are not TRUE. The routines have been inspired by similar mechanisms in the Swift programming language and discussion on the Swift design mailing lists. There are three assertion routines:

- precondition(x>0) to check inputs/environment before executing some code (to be used to check function arguments, for example)

- postcondition(.value. > 0) to check the function result 

- sanity_check(!is.null(x)) to check internal assumptions/invariants of the algorithm and guard against bugs, will immediately abort the program bypassing error handling when failed. Sanity checks are internal assertions and failing them always mean that there is a critical bug  in the code which would make any attempt at error recovery futile

Parts of the assertion predicate can be "embraced", which will print them on assertion failure, making it easier to see what went wrong, e.g. 

  x <- 0
  precondition({{x}} > 0)
  # Error:
  # ! precondition failure
  # ! `x > 0` is not TRUE
  #  
  #  `x` = dbl 10

The package README has some usage examples and background discussion. 

Thank you in advance for your help, 

Taras

P.S. To anticipate the mandatory (and justified) question, the reason why I decided to roll my own solution instead of using one of the existing packages (like the popular assertthat) is because I needed something very simple and with low performance overhead to help me debug my code and document program invariants. 


More information about the R-package-devel mailing list