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

From: Bill Dunlap <>
Date: Sat, 10 Nov 2007 17:04:28 -0800 (PST)

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

 "All statements in this message represent the opinions of the author and do  not necessarily reflect Insightful Corporation policy or position." mailing list Received on Sun 11 Nov 2007 - 01:08:31 GMT

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Sun 11 Nov 2007 - 03:30:25 GMT.

Mailing list information is available at Please read the posting guide before posting to the list.