Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve error localization #329

Closed
kpagacz opened this issue May 27, 2022 · 3 comments
Closed

Improve error localization #329

kpagacz opened this issue May 27, 2022 · 3 comments

Comments

@kpagacz
Copy link
Contributor

kpagacz commented May 27, 2022

rtables does not provide any error localization when it builds a table. The layout can be a "layered" structure with multiple functions piped one after another and the error is thrown once the build_table function is executed. When there are errors resulting from inappropriate application of the functions consisting of the layout there is no built-in rtables way of showing the user what layer caused the error. It makes layout functions unpleasant to debug.

Would be nice if the errors were giving some indication of what layer function actually caused the issue. In other words, it would be better if layer functions validated if the function can be executed and throw the error itself instead of delegating error throwing to private functions deep inside the package.

@gmbecker
Copy link
Collaborator

gmbecker commented Jun 8, 2022

Hi @kpagacz,

So what you're calling layer functions (as far as I can tell) i.e., split_rows_by, analyze, summarize_row_groups, etc, are not able to call the functions they are passed because they exist entirely before the data is available. This means there is no possible way to validate, e.g., custom splitting functions, during layout construction.

That said, I may be able to give some diagnostic information durring the breakdown process, and I will look into that.

Thanks for the report.

@kpagacz
Copy link
Contributor Author

kpagacz commented Jun 8, 2022

Indeed, rtables is designed in such a way that the entire layout is prepared before piping the data, and, understandably, any error throwing cannot happen during that time because there is no data yet.

Having that in mind, when data is piped, I have encountered errors thrown from functions deep inside rtables and I had no way of knowing what "layer" function caused the issue (traceback was not helpful). I had to deconstruct my layout, running it one by one with build_table to finally get the layer function that caused the issue. And then, the error was thrown from deep inside the package with an unhelpful message. Much better would be to check the pre-conditions inside the layer function instead of delegating it to a private function that I should not look at or catch any errors from the private functions and rethrow with a better message.

@gmbecker
Copy link
Collaborator

gmbecker commented Jun 8, 2022

We now give informative messages when user-specified functions break as of rtables version 0.5.1.3:

     afun <- function(x, .spl_context) {
        if(NROW(.spl_context) > 0 &&
           .spl_context[NROW(.spl_context), "value", drop = TRUE] == "WHITE")
            stop("error for white statistics")

        in_rows(myrow = 5)
    }

    lyt <- basic_table() %>%
        split_rows_by("ARM") %>%
        split_rows_by("RACE") %>%
        analyze("BMRKR1", afun = afun)

gives us

> build_table(lyt, DM)
Error in .make_analyzed_tab(df = df, spl = spl, cinfo = cinfo, lvl = lvl +  : 
  Error applying analysis function (var - BMRKR1): error for white statistics
	occured at (row) path: ARM[A: Drug X]->RACE[WHITE]

Errors for failures in custom cfuns (ie row group summary functions) and custom split functions are similarly informative.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants