Capturing output messages from the server side

Hi,

I was wondering what the best approach is for returning messages generated on the server side to the client side. I know that it is possible to test a condition on the server side, and if the condition fails, return a message. Instead I would like to capture messages generated by non-DS functions on the server side and return these. An example is for the lmer function with the verbose=TRUE option. This prints out the state of convergence at each iteration on the console. The question is how to return this to the client side.

So far the best I can do is to do:

out <- capture.output(try(result <- lmer(formula = BMI ~ trtGrp + Male + (1|idSurgery), data = dtPatient, verbose=TRUE)))

In this example, you still get the lmer object in ‘result’, but you also get the intermediate messages in ‘out’.

Does anyone know of a better way of doing this? I have searched existing functions for a way to do this and don’t think there is another way…

Thanks

Tom

Tom ,

I am not sure if it helps.

Try this structure

outcome <- TRUE

tryCatch(

{.logout(connection,save);},

warning = function(warning) {.warning(warning)},

error = function(error) {.error(error)},

finally = {return(outcome)}

)

All the name starting with a “.” Are helper functions.

P.

Dr Patricia Ryser-Welch

When restraint and courtesy are added to strength, the latter becomes irresistible.

Mahatma Gandhi

Start by doing what’s necessary; then do what’s possible; and suddenly you are doing the impossible.

Hi Tom,

I am probably misinterpreting what you are trying to do, and I don’t have a useful solution for it either!

I would make the point that if you are capturing native output server side that you shouldn’t send it to the client without parsing it first. While lmer may give the state of convergence at each iteration (which doesn’t sound disclosive) how does it behave under all (unknown) data situations? What if one of variables causes it to crash? Is there a chance it would dump a message that contains the cause of the problem (e.g. “variable X was out of range, here is the offending value”), which may then get passed back to the client?

You’re probably on top of this anyway - I just like to nag from time to time!

Cheers,

Olly

Hi Olly,

It’s a good point, I had thought that it would return anything that the lmer function generated (e.g. error messages), I hadn’t made the intellectual leap to thinking about this being disclosive.

I can probably validate that the messages are in the standard form for the iteration information and remove anything else.

Thanks for this useful point!

Tom

Tom,

Error handling at the server side could open some non-disclosive mechanism of the data. We have the same problem at our end. Perhaps we could work together with you, so that we collaboratively overcome this important issue.

Patricia