[Rd] C/C++ 'assert' should not be used in R packages

Duncan Murdoch 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.

Duncan Murdoch
>> 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
> 360-428-8146
>  "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 mailing list