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." ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel