Skip to content

[R-pkg-devel] Testing for a Specific R Error

6 messages · Bill Denney, Dirk Eddelbuettel, Henrik Bengtsson +1 more

Bill Denney
# 
Hi,

I got a message last night that some of the tests in the PKNCA package do not follow best practices.  ("Do not test the exact format of R messages (from R itself or from other packages): They change, and they can be translated.")  Specifically, I test to ensure that an error is generated when a class cannot be coerced into a data.frame: https://cran.r-project.org/web/checks/check_results_PKNCA.html

I want to ensure that I'm getting an error that the variable cannot be coerced into a data.frame.

What is the best practice to ensure that I'm getting a specific R error (about coercion) without testing the formatting of the error text?

The only solution that immediately occurs to me is to wrap the coercion in a tryCatch and give my own error.  But, then were the R error translated, the users of my package would lose the benefit of translation.

Thanks,

Bill
Dirk Eddelbuettel
#
On 2 December 2017 at 08:38, Bill Denney wrote:
| Hi,
| 
| I got a message last night that some of the tests in the PKNCA package do not follow best practices.  ("Do not test the exact format of R messages (from R itself or from other packages): They change, and they can be translated.")  Specifically, I test to ensure that an error is generated when a class cannot be coerced into a data.frame: https://cran.r-project.org/web/checks/check_results_PKNCA.html
| 
| I want to ensure that I'm getting an error that the variable cannot be coerced into a data.frame.
| 
| What is the best practice to ensure that I'm getting a specific R error (about coercion) without testing the formatting of the error text?

To me this suggest testing the _condition_ triggering the error message, as
opposed to testing for the displayed text of the error message.

Dirk
 
| The only solution that immediately occurs to me is to wrap the coercion in a tryCatch and give my own error.  But, then were the R error translated, the users of my package would lose the benefit of translation.
| 
| Thanks,
| 
| Bill
| 
| ______________________________________________
| R-package-devel at r-project.org mailing list
| https://stat.ethz.ch/mailman/listinfo/r-package-devel
Henrik Bengtsson
# 
For the translation part, you can test the received error message against
the translated message. You can get the translated version from the
original one using gettext("<non-translated error message exactly as the
original code does it>").

This should be agile to user's language settings but, of course, not to
changes that the developer does to the the error message.

Henrik
On Dec 2, 2017 05:38, "Bill Denney" <bill at denney.ws> wrote:
Hi,

I got a message last night that some of the tests in the PKNCA package do
not follow best practices.  ("Do not test the exact format of R messages
(from R itself or from other packages): They change, and they can be
translated.")  Specifically, I test to ensure that an error is generated
when a class cannot be coerced into a data.frame:
https://cran.r-project.org/web/checks/check_results_PKNCA.html

I want to ensure that I'm getting an error that the variable cannot be
coerced into a data.frame.

What is the best practice to ensure that I'm getting a specific R error
(about coercion) without testing the formatting of the error text?

The only solution that immediately occurs to me is to wrap the coercion in
a tryCatch and give my own error.  But, then were the R error translated,
the users of my package would lose the benefit of translation.

Thanks,

Bill

______________________________________________
R-package-devel at r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Duncan Murdoch
#
On 02/12/2017 9:23 AM, Dirk Eddelbuettel wrote:
Isn't that what Bill suggested in the line below?

 > | The only solution that immediately occurs to me is to wrap the 
coercion in a tryCatch and give my own error.  But, then were the R 
error translated, the users of my package would lose the benefit of 
translation.

R does have a system for giving language-independent information about 
errors and warnings:  see the ?signalCondition help page. 
Unfortunately, support for this at the C level is missing, so base 
functions generally don't use it.  You only get something of class 
c("simpleError", "error", "condition").

I don't think there's anything better than Bill's solution, though I 
imagine it is possible to ask for translation of the message.  For 
example, sqrt(-1) currently gives a warning with English message "NaNs 
produced".

I can ask to translate that into the current session language using

gettext("NaNs produced", domain = "R")

Figuring out the right thing for "domain" is likely a little painful: 
it depends on which package produced the message, and how.

I don't know if CRAN tests would complain if you tested for equality 
between a warning message and the result of gettext():  it's still true 
that if the English warning changed, the test would fail.

Duncan Murdoch
Bill Denney
# 
Another idea just occurred to me.  Get the current error text as I'm expecting it from R by generating the error in a tryCatch and then test for equality to that string.  With that, changes in R (or other packages) would be automatically updated, and it would still be a precise test for the error I'm wanting to confirm in my test:

tryCatch(as.data.frame(structure(1, class="foo")), error=function(e) e$message)

Capture the output of that tryCatch and test for equality.

Then, it will be robust to language changes and to changes in R or other packages.

I'm going to implement that unless someone indicates something that I'm missing.

Thanks,

Bill
Duncan Murdoch
#
On 02/12/2017 2:19 PM, Bill Denney wrote:
That sounds like a really good idea.  It should work in your use case, 
though in cases where the error message includes information about the 
arguments that led to the error (e.g. vignette("foobar") says "vignette 
?foobar? not found" in English and "vignette ?foobar? introuvable" in 
French) it might be harder.

Duncan Murdoch