Get rror CRAN-ready

[alistaire47]

Last month I started rror as a hackathon project. In short, it's a wrapper of base R condition (error, warning, message, etc) handling utilities to make them more accessible and comprehensible to package developers and users than the somewhat lacking documentation at ?conditions. It makes it really simple to raise and catch classed conditions, so if developers want an equivalent of Python's ValueError, AssertionError, etc, they can create one, and users can catch specific conditions by class, ignoring others.

The goal of this issue is to get rror ready for CRAN, as as a package meant to be used primarily as a dependency, it's not much use until its there. Accomplishing this divides into two high-level tasks, in my view:

• Work on open issues necessary for package robustness (unit tests, CI, pkgdown site, etc.)
• Decide if the API is right or needs altering or extension (this package is still alpha). This task is much broader and more open-ended, but a few issues I'm presently mulling:
  • Is except the right interface for catching conditions? Should it be renamed or changed into an infix function or something?
  • Should prebuilt classed conditions be included so they're more likely to exist in the same form across packages? If so, which? Going through the built-in Python ones might be a good starting point.
  • Should there be a shortcut to raising an error that does not require creating a condition beforehand? E.g. raise_error(class = "input_error", message = "your input for x is wonky"). This looks a lot like rlang::abort(), for better or worse. Making conditions R6 objects with a raise() method is also possible, if people really like R6, though it would add it as a dependency.

Help and input on any/all of the above are welcome. If you'd like to learn about

• conditions (What's the difference between tryCatch() and withCallingHandlers()? What's a restart?) or
• package development and best practices,

you may find an interesting task here!

[jameslamb]

@alistaire47 I think it would be useful to group your issues with milestones so people can tell the difference between issues that are "steps toward CRAN" and others that are just "things to do eventually".

[jameslamb]

@alistaire47 I was just reading the running changes coming in R 4.0.0 docs and noticed this under "New Features":

assertError() and assertWarning() (in package tools) can now check for specific error or warning classes via the new optional second argument classes (which is not back compatible with previous use of an unnamed second argument).

[alistaire47]

Interesting! tryCatch can already catch classes:

tryCatch(stop(errorCondition('message', class = 'error_class')), error_class = print)
#> <error_class: message>

though not for repeated conditions, which require withCallingHandlers and some work with restarts. But this seems more like testthat::expect_error? Not sure if I totally understand what problem it's solving.

The real problem is that devs don't class conditions in the first place. I don't honestly care if anyone ever uses this package if it encourages devs to use already-available tools to set up better classes and restarts. Including r-core, tbh.