0

Does this look like reasonable code to capture an error, flag that there was an error, log it, and move on?

  8 cdb.retrieveData <- function(url) {
  9   errors <- c()
 10   success <- TRUE
 11   onError <- function(e) {
 12     errors <<- c(errors, sprintf("Failed retrieval \"%s\", error: %s",
 13       url, e$message))
 14     success <<- FALSE
 15     list()
 16   }
 17   data <- tryCatch(fromJSON(url), error=onError, warning=onError)
 18   list(url=url, success=success, errors=errors, data=data)
 19 }

I think the list() of line 15 will be returned from tryCatch() on error and take the place of data in the returned list.

The code looks pretty similar to that suggested in https://stackoverflow.com/a/39898082/608359 Is there a better way?

This code is producing "Error in sprintf("Failed retrieval \"%s\", error: %s", url, e$message) : promise already under evaluation: recursive default argument reference or earlier problems?". What is the cause?

If it matters, the caller is a reduce from purrr whose reducer combines the returned lists into one. The mess that calls it is this source processContests.R

I'm afraid I haven't been able to reproduce the error in a test. It's probably premature of me to be asking here. Here's the series of calls which gets me to the error.

> cdb <- CDBContests('https://iaccdb.iac.org')
> ctsts <- cdb$allContests()
> pc <- ProcessContests(ctsts)
> pc$process()
[1] Processed records file, "pc_processed.rds" retrieval error: "cannot open compressed file 'pc_processed.rds', probable reason 'No such file or directory'". NOTE: Processing all contests.
[1] Errors file, "pc_errors.rds" retrieval error: "cannot open compressed file 'pc_errors.rds', probable reason 'No such file or directory'". Will start one.
[1] Data file, "pc_data.rds" retrieval error: "cannot open compressed file 'pc_data.rds', probable reason 'No such file or directory'". Starting data file.
Error in sprintf("Failed retrieval \"%s\", error: %s", url, e$message) :
  promise already under evaluation: recursive default argument reference or earlier problems?
>
Douglas Lovell
  • 1,549
  • 17
  • 27
  • 1
    Here's what I do. It runs an expression and then stores warnings and errors associated with it in a list. https://stackoverflow.com/q/4948361/210673 See also the various answers there which improve the code in several ways, and Hadley's pointer to the `evaluate` package. – Aaron left Stack Overflow Oct 08 '19 at 02:20
  • 1
    I'd have `onError` return `NA` with the error/warning message as an attribute. I can't easily reproduce the error you are seeing. Can you share an URL that triggers this error? Does it happen outside `reduce`? Your problem is likely related to your use of purrr. The tidyverse likes to get fancy with evaluation (and Hadley et al. create packages just to deal with the problems that result from that). – Roland Oct 08 '19 at 06:05
  • Thank you for the comments. I've added a little more background. The referenced answers treat warnings differently than errors. In particular, calling `invokeRestart("muffleWarning")`. They also layer the call to `tryCatch` (with an error handler) inside of a `withCallingHandlers` (with the warning handler). Is all of that necessary? I'll have to mess with it some more or try to understand it better, which will happen in a few days. If this turns out to be that I'm not doing my own homework and asking a duplicate, if it isn't adding anything, don't be shy. Let me know. That's very possible. – Douglas Lovell Oct 08 '19 at 11:44
  • Thank you for the comments. Here's a gist https://gist.github.com/wbreeze/86e187cf0800783df9ca1e5b997ddc74 The approach using reduce() and tryCatch() works in the gist. The problem must be somewhere else. I'll leave the question for now, while working-out the somewhere else. – Douglas Lovell Oct 14 '19 at 22:35
  • Coding the try and capture error using the nested strategy referenced in https://stackoverflow.com/q/4948361/210673 solved the problem. Using the same handler for the error and the warning resulted in a recursion due to a warning issued by the promise when it retries. The referenced code captures that warning in an outer environment and resumes where the warning came from. In other words, the answer to my Oct 8 question, "Is all of that necessary?" is yes. I've voted to close this (my own question) as a duplicate. – Douglas Lovell Oct 16 '19 at 07:07

0 Answers0