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

[Bill Dunlap]

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.

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.

> 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."