Matthew Carlucci
2020-Jun-25 18:21 UTC
[Rd] Unexpected Error Handling by Generic in R 4.0.1
Hello R-devel community, I posted a new R 4.0.1 behaviour to stack overflow (https://stackoverflow.com/questions/62327810/inconsistent-error-handling-of-function-and-s4-generics-on-r-4-0-1), where I think it is an undesired or unexpected change in 4.0.1. Attributes of errors seem to be lost or obscured when encountered in an S4 generic context. An example of this being undesirable comes in shiny applications where my_reactive (an unevaluated reactive object) returns a shiny.silent.error attribute which is lost upon error within an S4 generic function. The lack of this attribute causes the entire application to exit with an error (with no stack trace available). For example, within a shiny context:> foo <- try(nrow(my_reactive()))> attr(foo,"condition")<shiny.silent.error: > Where the S4 generic returns:> bar <- try(BiocGenerics::nrow(my_reactive()))> attr(bar,"condition")<simpleError in (function (cond) .Internal(C_tryCatchHelper(addr, 1L, cond)))(structure(list(message = ""), class = c("shiny.silent.error", "validation", "error", "condition"), stack.trace = [... lots more output here ...]: error in evaluating the argument 'x' in selecting a method for function 'nrow': >>From what I can tell from the release notes of 4.0.1, this does not appear to be an expected breaking change so I am hesitant to update old code and shiny applications to account for this behaviour. Any guidance would be appreciated.Thank you, Matthew Carlucci CONFIDENTIALITY NOTICE: This e-mail message, including a...{{dropped:18}}
iuke-tier@ey m@iii@g oii uiow@@edu
2020-Jun-25 21:59 UTC
[Rd] [External] Unexpected Error Handling by Generic in R 4.0.1
Thanks for the report. This is due to a change restoring behavior that was disabled temporarily to work around a bug (https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16111). So it is again working as originally designed. There are a number of places in the S4 dispatch code where errors are caught and re-signaled with some additional information about the dispatch context that might be helpful. Unfortunately all that is retained from the original error is the message. It would be better to signal a structured error object that includes the original error in a slot. Some options: Create and signal a structured error wrapping the original error in these cases. Revert the argument evaluation to not wrap errors. Drop wrapping of error from all other cases. I don't have strong views on which way to go. But wrapping and re-signaling from C would take a decent amount of effort so isn't likely to happen without someone contributing a well-tested patch. Best, luke On Thu, 25 Jun 2020, Matthew Carlucci wrote:> Hello R-devel community, > > I posted a new R 4.0.1 behaviour to stack overflow (https://stackoverflow.com/questions/62327810/inconsistent-error-handling-of-function-and-s4-generics-on-r-4-0-1), where I think it is an undesired or unexpected change in 4.0.1. Attributes of errors seem to be lost or obscured when encountered in an S4 generic context. > > An example of this being undesirable comes in shiny applications where my_reactive (an unevaluated reactive object) returns a shiny.silent.error attribute which is lost upon error within an S4 generic function. The lack of this attribute causes the entire application to exit with an error (with no stack trace available). For example, within a shiny context: > >> foo <- try(nrow(my_reactive())) > >> attr(foo,"condition") > > <shiny.silent.error: > > > Where the S4 generic returns: > >> bar <- try(BiocGenerics::nrow(my_reactive())) > >> attr(bar,"condition") > > <simpleError in (function (cond) .Internal(C_tryCatchHelper(addr, 1L, cond)))(structure(list(message = ""), class = c("shiny.silent.error", "validation", "error", "condition"), stack.trace = [... lots more output here ...]: error in evaluating the argument 'x' in selecting a method for function 'nrow': > > > From what I can tell from the release notes of 4.0.1, this does not appear to be an expected breaking change so I am hesitant to update old code and shiny applications to account for this behaviour. Any guidance would be appreciated. > > Thank you, > > Matthew Carlucci > > CONFIDENTIALITY NOTICE: This e-mail message, including a...{{dropped:18}} > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >-- Luke Tierney Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics and Fax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: luke-tierney at uiowa.edu Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu