1

I participate in the development of R packages that grab data in web databases. These packages contain examples and tests which good execution depends on network and server availability.

Obviously, when the communication is down, the CRAN check fails because of errors in tests and examples. In that case, the CRAN team asked me to "handle web access problems gracefully".

The matter is that I don't know at which stage this handling is the most relevant. And I don't find any solution that is totally satisfying among the following solutions.

Catch the error in the function and returns no error ?

This solution is adopted by the package NHSDataDictionaRy, where the error is caught, a print in the console advises that something wrong occurred and returns a NULL value. In the vignette, a is.null condition checks if further calculations can be run.

I'm not satisfied with this solution because the user must handle the potential error. If he forgets it, an error can occur in a downstream process tricky to debug or, worse still, the process can continue to run returning wrong values.

Remove execution of tests and examples on CRAN

The skip_on_cran statement is an easy way to avoid any problems as long as these tests are regularly executed by the dev team in order to detect unfortunate changes in APIs. Anyway, tests can be carefully designed to handle this.

For the examples, the simple answer is to add /dontrun{} statements which, degrades a bit the user experience.

Chunks with option error=TRUE?

This option allows to don't crash the vignette compilation in case of error. I don't know if the CRAN accepts this solution. However, unless the considered chunk has no side effect, this does not exclude the need of a manual error handling.

tryCatch everywhere?

Add a tryCatch and handle manually potential errors in tests, examples and vignettes.

I find this solution a bit cumbersome, especially for the examples which need to be as simple to understand as possible.

So, what would be the doctrine to follow for handling this issue correctly?

David Dorchies
  • 336
  • 2
  • 11
  • 1
    The best solution is the last one, using `tryCatch` on anything that might fail (or at least on anything that is tested that might fail). To make it less cumbersome, put wrappers on functions that hold the `tryCatch` calls, and define some return value that indicates "the Internet is down". Using `skip_on_cran` is fine in tests. You shouldn't be relying on CRAN to run your tests, you should have regular test runs during development (e.g. via Github actions). – user2554330 Mar 14 '22 at 09:17

0 Answers0