From murdoch at stats.uwo.ca  Sun Nov 11 03:38:11 2007
From: murdoch at stats.uwo.ca (Duncan Murdoch)
Date: Sat, 10 Nov 2007 21:38:11 -0500
Subject: [Rd] C/C++ 'assert' should not be used in R packages
In-Reply-To: <Pine.GSO.4.56.0711101650190.18407@durian.statsci.com>
References: <Pine.LNX.4.64.0711071638510.7944@gannet.stats.ox.ac.uk>
	<47359829.8090909@stats.uwo.ca>
	<Pine.GSO.4.56.0711101650190.18407@durian.statsci.com>
Message-ID: <47366B13.8020205@stats.uwo.ca>

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



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