try() wrapper

[hadley]

Maybe maybe()? Should it be a wrapper around functions or around expressions?

library(purrr)
maybe1 <- function(expr, otherwise, quiet = TRUE) { 

  if (missing(otherwise)) { 
    try(expr, silent = quiet)
  } else {
    tryCatch(expr,
      error = function(e) {
        if (!quiet)
          message("Error: ", e$message)
        otherwise
      }
    )
  }
}

maybe2 <- function(f, otherwise, quiet = TRUE) {
  if (missing(otherwise)) { 
    function(...) {
      try(f(...), silent = quiet)  
    }
  } else {
    function(...) {
      tryCatch(f(...),
        error = function(e) {
          if (!quiet)
            message("Error: ", e$message)
          otherwise
        }
      )
    }
  }
}


maybe1(log("a"))
maybe1(log("a"), NULL)

maybe2(log)("a")
maybe2(log, NULL)("a")

"a" %>% map(~ maybe1(log(.)))
"a" %>% map(maybe2(log))

cc @jennybc, @lionel-

[lionel-]

The first one feels more like traditional "throw/catch" error handling, while the second feels more functional, and can be composed with other function operators. So I prefer the second form.

[jennybc]

I like the second one but for a different reason. I am less comfortable with expressions and it gives me the option to define the function, then use it with map().

safe_log <- maybe2(log)
list("a", exp(1)) %>% map(safe_log)

On a slight tangent, I am repeatedly surprised that try() silences fatal errors and still lets warnings through. It feels like it should work more like logging levels. Would you ever consider a version where quiet suppresses warnings?

## how can this be silent?
maybe2(log)("a")
## and this be not?
maybe2(log)(-1)
#> Warning in f(...): NaNs produced
#> [1] NaN

[lionel-]

or have another function operator, silently()? It would fail on errors but suppress messages and warnings.

I am repeatedly surprised that try() silences fatal errors and still lets warnings through.

The problem is that you may not know a warning went through then. That's a big difference with errors which show up as either a "try-error" object or as a user-specified default value. It is a bit dangerous to silence warnings completely so it should be really explicit that it's what the user wants. If we add this option to maybe(), it should probably be another argument, such as silent = FALSE (which could call silently() on the resulting function).

[hadley]

Another option is to bring in something like testthat::evaluate_promise(). It's a terrible name but the idea is good - it basically turns all side effects into outputs, so you get a list of result, output, messages and warnings (errors are passed through unchanged).

I'd kind of prefer try() to work like that - instead of sometimes returning a try-error and sometimes returning something else, I'd prefer it to always returning a list with components result and error (and one would always be empty)

[hadley]

Oooh, I rather like that:

library(purrr)
safe <- function(f, quiet = TRUE) {
  show_error <- function(e) {
    if (quiet) return()

  }
  function(...) {
    tryCatch(list(result = f(...), error = NULL),
      error = function(e) {
        if (!quiet)
          message("Error: ", e$message)

        list(result = NULL, error = e)
      }
    )
  }
}

safe_log <- safe(log)
out <- list("a", exp(1)) %>% map(safe_log)
zip_n(out)

Especially since it works so naturally with zip.

I'm not sure if safe() is the right name, but it does seem a bit different to maybe(). I'm also not sure if we need both safe() and maybe()

[hadley]

Are there other side-effecty things that we could also capture this way?

[jennybc]

The safe() above is great (and a 💡just went on re: what zip_n() is good for).

Could quiet work like options(warn=2)? So warnings become errors, both are silenced, and get duly recorded in error?

[hadley]

@jennybc would you prefer that to having warnings stored separately in their own warnings slot?

[jennybc]

I don't feel qualified to say. I suppose it's possible to get both a warning and an error?

[lionel-]

safe() is a nice idea. How about calling it something along the lines of effects()? Since it returns a list of all effects.

I think there's room for maybe(), silently() and effects() as each has its own purpose.

Are there other side-effecty things that we could also capture this way?

Can we capture printed outputs issued by cat()?

[lionel-]

How about calling it something along the lines of effects()? Since it returns a list of all effects.

Though it doesn't capture assignments, so it won't be about all effects.

[hadley]

We can only capture "output" effects, so maybe outputs()?

We can capture:

• printed output to console
• messages
• warnings
• (one) error

The question to me is whether this should be one function with an optional argument to capture errors, or two functions, one regular outputs and one for errors. I think we'd still want maybe() for the cases where you don't care about the error, you just want to replace it with a default value.

[hadley]

Checked in a first pass, mostly for discussion. I'm not confident about the names or the exact breakdown of tasks between functions.