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