Test for overlapping analysis intervals with get_halflife_points()

[john-harrold]

When I try to use get_halflife_points() and I have analysis intervals that overlap for example two analytes over the same interval or one analyte but specifying overlapping intervals (e.g. 0-14 days and also 0-inf), I get the error below. I understand why it's doing that :). My question is can I test for this programmatically so I can run get_halflife_points() conditionally and also send a message back to the user about why certain things wont be displayed?

Error in get_halflife_points.PKNCAresults(nca_res) : 
  More than one half-life calculation was attempted on the following rows: 1, 2, 3, 4, 5, 6, 7

[billdenney]

My typical method would be to run it inside try() to capture the error. If you'd like, we could make it a classed error so that testing for it would be simpler.

[john-harrold]

I would prefer a test of some kind. I can run it in a try/catch, but it's hard to distinguish that from some other random error. If it fails a try/catch, I just return the error to the user. Which isn't as clean and understandable as. If I have a test I can return something meaningful.

[Gero1999]

@john-harrold Would it work if you combine withCallingHandlers with a function to customize the error message conditionally on a regex? Something like:

hl_points <- withCallingHandlers({
  get_halflife_points(...)
}, error = function(e) {
    parse_err_msg(e)
}
})


# Helper function to customize the error message when the input
# is "More than one half-life calculation..."
parse_err_msg <- function(e) {
...
}

Will this strat be a valid answer? Or you are looking for something different in the UI?

[billdenney]

My preference here is that this (and all) error and all warnings are classed so that they are easily testable/findable for people automating around PKNCA.

[john-harrold]

It would be cool if I could call PKNCA in such a way that I specify I'm running non-interactively. When run in this fashion it returns like normal with some method I could run against the result to determine if there was an error and pull out any verbose error messages in that error.

[billdenney]

The simple answer for that is silently and safely from the purrr package.