[R-pkg-devel] Falling gracefully in subsequent code

Thank you all for the kind suggestions! Dirk's advice (in the same spirit
of Hadely's suggestion) should work like a glove !

For the record, I really appreciate how supportive the R community (and
this group in particular) is. Thanks a bunch and happy New Year!

best,
Rafa Pereira

On Tue, Dec 30, 2025 at 2:54?PM Hadley Wickham <h.wickham at gmail.com>
wrote:

Or slightly simpler (if less helpful), you can do something like:

if (is.null(df)) {
  knitr::opts_chunk(eval = FALSE)
}

Hadley

On Mon, Dec 29, 2025 at 7:23?PM Michael Chirico <

michaelchirico4 at gmail.com>

wrote:

At a glance you might try a hidden code chunk that looks for NULL input
and
populates a "fake" dataset if so.

On Mon, Dec 29, 2025, 4:35?PM Rafael H. M. Pereira <
rafa.pereira.br at gmail.com> wrote:

Hi all,

I would very much appreciate your thoughts on this situation.

# context
I received an email from Prof Ripley saying that my package is not

"falling

gracefully". Error report here
https://www.stats.ox.ac.uk/pub/bdr/Rblas/ATLAS/aopdata.out

The error happens in the code below. You see, in the case of an

internet

connection issue, the aopdata::read_population() function returns a

silent

NULL plus an informative message, as it should. So my package does in

fact

fail gracefully whenever an internet connection is unavailable.

In this case, though, the error is actually happening in the ggplot2

call.

Because the df object is NULL, ggplot2 cannot find the "P001" column.

In

short, the package itself does follow CRAN's policy when there is an
eventual internet connection issue, but the subsequent code throws an

error

in such a case.

Given this behavior, I?m not sure there is a change I could make to my
package that would fully prevent this situation, other than removing
vignettes that demonstrate how to use the function outputs, which I

would

prefer to avoid if possible.

# the situation
When I asked for advice, a kind Cran maintainer said: "So it is not

good

enough to have a function return NULL when the subsequent code will

throw

an error when it gets that NULL."

So here is the situation. The Cran Policy (see it below) requires *the
package* to fail gracefully. It does not mention subsequent code.

Imho,

it

should not require any subsequent code to fail gracefully. As a
package developer, I only have control over the functioning of my

package,

I cannot control what code users will use to analyze the output of my
package functions.

If necessary, I will simply not run the ggplot calls in my vignettes

and

render pre-generated plots saved in .png. I feel this would be a bad
solution to keep the package on CRAN, though. I would really

appreciate

your thoughts on this.

best,
Rafael Pereira

*Cran Policy asks that:*

   - Packages which use Internet resources should fail gracefully with
an informative
   message if the resource is not available or has changed (and not

give a

   check warning nor error)


# code causing the error

library(aopdata)
library(ggplot2)
df <- aopdata::read_population
<https://ipeagit.github.io/aopdata/reference/read_population.html>(
city = 'Fortaleza',  year = 2010,  geometry = TRUE,  showProgress =
FALSE  )



ggplot() +
  geom_sf(data=subset(df, P001>0), aes(fill=P001), color=NA,

alpha=.8) +

  scale_fill_distiller(palette = "YlOrRd", direction = 1)+
  labs(title='Population distribution', fill="Total population") +
  theme_void()


best,
Rafael Pereira

        [[alternative HTML version deleted]]

        [[alternative HTML version deleted]]

--
http://hadley.nz

        [[alternative HTML version deleted]]

Sharing here a solution I was happy with:

```{r, eval=!is.null(df), ...}

this has the advantage of hiding the distracting edge case handling from
the expository code being shown to the vignette reader.

Mike C

On Thu, Jan 1, 2026, 4:53?PM Rafael H. M. Pereira <
rafa.pereira.br at gmail.com> wrote:

Thank you all for the kind suggestions! Dirk's advice (in the same spirit
of Hadely's suggestion) should work like a glove !

For the record, I really appreciate how supportive the R community (and
this group in particular) is. Thanks a bunch and happy New Year!

best,
Rafa Pereira

On Tue, Dec 30, 2025 at 2:54?PM Hadley Wickham <h.wickham at gmail.com>
wrote:

Or slightly simpler (if less helpful), you can do something like:

if (is.null(df)) {
  knitr::opts_chunk(eval = FALSE)
}

Hadley

On Mon, Dec 29, 2025 at 7:23?PM Michael Chirico <

michaelchirico4 at gmail.com>

wrote:

At a glance you might try a hidden code chunk that looks for NULL input
and
populates a "fake" dataset if so.

On Mon, Dec 29, 2025, 4:35?PM Rafael H. M. Pereira <
rafa.pereira.br at gmail.com> wrote:

Hi all,

I would very much appreciate your thoughts on this situation.

# context
I received an email from Prof Ripley saying that my package is not

"falling

gracefully". Error report here
https://www.stats.ox.ac.uk/pub/bdr/Rblas/ATLAS/aopdata.out

The error happens in the code below. You see, in the case of an

internet

connection issue, the aopdata::read_population() function returns a

silent

NULL plus an informative message, as it should. So my package does in

fact

fail gracefully whenever an internet connection is unavailable.

In this case, though, the error is actually happening in the ggplot2

call.

Because the df object is NULL, ggplot2 cannot find the "P001"

column. In

short, the package itself does follow CRAN's policy when there is an
eventual internet connection issue, but the subsequent code throws an

error

in such a case.

Given this behavior, I?m not sure there is a change I could make to

my

package that would fully prevent this situation, other than removing
vignettes that demonstrate how to use the function outputs, which I

would

prefer to avoid if possible.

# the situation
When I asked for advice, a kind Cran maintainer said: "So it is not

good

enough to have a function return NULL when the subsequent code will

throw

an error when it gets that NULL."

So here is the situation. The Cran Policy (see it below) requires

*the

package* to fail gracefully. It does not mention subsequent code.

Imho,

it

should not require any subsequent code to fail gracefully. As a
package developer, I only have control over the functioning of my

package,

I cannot control what code users will use to analyze the output of my
package functions.

If necessary, I will simply not run the ggplot calls in my vignettes

and

render pre-generated plots saved in .png. I feel this would be a bad
solution to keep the package on CRAN, though. I would really

appreciate

your thoughts on this.

best,
Rafael Pereira

*Cran Policy asks that:*

   - Packages which use Internet resources should fail gracefully

with

an informative
   message if the resource is not available or has changed (and not

give a

   check warning nor error)


# code causing the error

library(aopdata)
library(ggplot2)
df <- aopdata::read_population
<https://ipeagit.github.io/aopdata/reference/read_population.html>(
city = 'Fortaleza',  year = 2010,  geometry = TRUE,  showProgress =
FALSE  )



ggplot() +
  geom_sf(data=subset(df, P001>0), aes(fill=P001), color=NA,

alpha=.8) +

  scale_fill_distiller(palette = "YlOrRd", direction = 1)+
  labs(title='Population distribution', fill="Total population") +
  theme_void()


best,
Rafael Pereira

        [[alternative HTML version deleted]]

        [[alternative HTML version deleted]]

--
http://hadley.nz

        [[alternative HTML version deleted]]