[Rd] C/C++ 'assert' should not be used in R packages
murdoch at stats.uwo.ca
Sun Nov 11 03:38:11 CET 2007
Bill Dunlap wrote:
> On Sat, 10 Nov 2007, Duncan Murdoch wrote:
>> Prof Brian Ripley wrote:
>>> Please don't use 'assert' in R packages. If called, this means that an
>>> error in your code aborts the whole R process, including your user's work.
>>> I see several R packages doing this, and one of them called 'assert' on me
>>> earlier in the week.
>> I partly disagree about this. If assert() is triggered, it clearly
>> indicates a bug in the package. If it just generated an R error, most
>> users would ignore it, and not report it to the package maintainer.
>> It may well be that when an assertion fails, none of the subsequent
>> calculations are reliable, in which case returning control to the user
>> could result in data corruption. That's worse than losing a session,
>> because at least when you lose a session, you know it.
> I would think one would want to call assert() before doing something
> that might corrupt the session. Sometimes you cannot arrange to
> do that, but most times you can.
Sometimes assertions fail because the session is already corrupted. The
thing about assertions is that they aren't supposed to fail.
> I think it would be nice to have a class of "programmer errors",
> as opposed to "user errors". (A user error is when the user enters
> inappropriate data for the function and a programmer error is
> when the inputs are appropriate but the code in the package is bad.)
> Supply functions at the R and C levels (assert() and Rf_assert(),
> respectively?) to throw such errors. They would work about the
> same as stop() and Rf_error() do (longjmp to main input loop),
> but would print something like
> 'Internal/programmer error, report to authorities: n<0'
> instead of
> 'Error: n is negative'
> If the message automatically included the package name, file name,
> and line number for C code, so much the better, but the text of the message
> should identify it.
> You could install a special error handler for that class of errors
> if you wished.
I think that would be a good idea.
>> Could we write our own implementation of assert() that displays an R
>> error and unloads the package? I think I could do something like that
>> in Windows by calling FreeLibrary to unload the DLL, but I'd prefer a
>> cross-platform solution.
> Bill Dunlap
> Insightful Corporation
> bill at insightful dot com
> "All statements in this message represent the opinions of the author and do
> not necessarily reflect Insightful Corporation policy or position."
More information about the R-devel