Re: [Rd] C/C++ 'assert' should not be used in R packages
On Nov 10, 2007 1:27 PM, Simon Urbanek [EMAIL PROTECTED] wrote: On Nov 10, 2007, at 1:05 PM, Duncan Murdoch wrote: On 10/11/2007 1:00 PM, Duncan Temple Lang wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. 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. I am not sure why you think we need to discard the DLL. The package author has asserted that it is no longer safe to run. They are shutting down R, and Brian finds that too extreme. Me too. A package should never intentionally close the R session. If it does, it is a very severe design bug in the package (IMHO). Anything you use assert for can be gracefully handled (as opposed to let's say a segfault), so there is no excuse for killing the whole process at all (deliberately wiping all user's work is rude to put it mildly). Oh, I normally try to wipe the harddrive too when I'm at it ;) /H Even if it might be unsafe to run anything, I'd still want to attempt to save my data. Cheers, Simon What if we want to access variables and routines merely to find out the resulting state after the assert(). And it is not clear whether you mean any subsequent calculations or any subsequent calculations using code within this DLL might be unreliable. How could I know why a package author decided a shutdown is needed? It depends on the author. But regardless of that and the assumption that users will ignore this error, why would you want to call FreeLibrary? Since R has induced the DLL to be loaded either directly or indirectly, R holds a handle to the DLL. If you don't use R's cross-platform facilities for releasing the DLL (either at the R or C-level), you will corrupt the session, specifically in the list of assumed-live DLLs. As I said, I'd prefer a cross-platform solution. Duncan Murdoch D. We provide 'error': please do use it to return control to the user when your code misbehaves. Similarly 'exit' and 'abort' should never be used in R packages. Sometimes it is not under your control: I sometimes see an rgl failure at R: indirect_vertex_array.c:659: emit_DrawArrays_old: Assertion `elements_per_request = count' failed. that is coming from the Mesa GL libraries. I'd say that's a bug, either in Mesa GL or in rgl. If you can make it reproducible, I'll try to track it down. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHNfHA9p/Jzwa2QP4RAo2BAJkB5QaFLOW5fcR6QE9JSXpIWAcEUwCggMYK 2WBnl5jDgTUayU5wk8hnQj4= =91by -END PGP SIGNATURE- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C/C++ 'assert' should not be used in R packages
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. 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. We provide 'error': please do use it to return control to the user when your code misbehaves. Similarly 'exit' and 'abort' should never be used in R packages. Sometimes it is not under your control: I sometimes see an rgl failure at R: indirect_vertex_array.c:659: emit_DrawArrays_old: Assertion `elements_per_request = count' failed. that is coming from the Mesa GL libraries. I'd say that's a bug, either in Mesa GL or in rgl. If you can make it reproducible, I'll try to track it down. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C/C++ 'assert' should not be used in R packages
On 10/11/2007 6:38 AM, 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. 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. I've put an implementation of this into rgl (svn only for now, not on CRAN). I didn't bother with the FreeLibrary call, the error message asks the user to inform the maintainer. It won't help with the Mesa GL problem below, as that's not rgl code, but at least now I won't feel bad about including assert()'s in my code. Duncan Murdoch We provide 'error': please do use it to return control to the user when your code misbehaves. Similarly 'exit' and 'abort' should never be used in R packages. Sometimes it is not under your control: I sometimes see an rgl failure at R: indirect_vertex_array.c:659: emit_DrawArrays_old: Assertion `elements_per_request = count' failed. that is coming from the Mesa GL libraries. I'd say that's a bug, either in Mesa GL or in rgl. If you can make it reproducible, I'll try to track it down. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C/C++ 'assert' should not be used in R packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. 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. I am not sure why you think we need to discard the DLL. What if we want to access variables and routines merely to find out the resulting state after the assert(). And it is not clear whether you mean any subsequent calculations or any subsequent calculations using code within this DLL might be unreliable. But regardless of that and the assumption that users will ignore this error, why would you want to call FreeLibrary? Since R has induced the DLL to be loaded either directly or indirectly, R holds a handle to the DLL. If you don't use R's cross-platform facilities for releasing the DLL (either at the R or C-level), you will corrupt the session, specifically in the list of assumed-live DLLs. D. We provide 'error': please do use it to return control to the user when your code misbehaves. Similarly 'exit' and 'abort' should never be used in R packages. Sometimes it is not under your control: I sometimes see an rgl failure at R: indirect_vertex_array.c:659: emit_DrawArrays_old: Assertion `elements_per_request = count' failed. that is coming from the Mesa GL libraries. I'd say that's a bug, either in Mesa GL or in rgl. If you can make it reproducible, I'll try to track it down. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHNfHA9p/Jzwa2QP4RAo2BAJkB5QaFLOW5fcR6QE9JSXpIWAcEUwCggMYK 2WBnl5jDgTUayU5wk8hnQj4= =91by -END PGP SIGNATURE- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C/C++ 'assert' should not be used in R packages
On 10/11/2007 1:00 PM, Duncan Temple Lang wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. 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. I am not sure why you think we need to discard the DLL. The package author has asserted that it is no longer safe to run. They are shutting down R, and Brian finds that too extreme. What if we want to access variables and routines merely to find out the resulting state after the assert(). And it is not clear whether you mean any subsequent calculations or any subsequent calculations using code within this DLL might be unreliable. How could I know why a package author decided a shutdown is needed? It depends on the author. But regardless of that and the assumption that users will ignore this error, why would you want to call FreeLibrary? Since R has induced the DLL to be loaded either directly or indirectly, R holds a handle to the DLL. If you don't use R's cross-platform facilities for releasing the DLL (either at the R or C-level), you will corrupt the session, specifically in the list of assumed-live DLLs. As I said, I'd prefer a cross-platform solution. Duncan Murdoch D. We provide 'error': please do use it to return control to the user when your code misbehaves. Similarly 'exit' and 'abort' should never be used in R packages. Sometimes it is not under your control: I sometimes see an rgl failure at R: indirect_vertex_array.c:659: emit_DrawArrays_old: Assertion `elements_per_request = count' failed. that is coming from the Mesa GL libraries. I'd say that's a bug, either in Mesa GL or in rgl. If you can make it reproducible, I'll try to track it down. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHNfHA9p/Jzwa2QP4RAo2BAJkB5QaFLOW5fcR6QE9JSXpIWAcEUwCggMYK 2WBnl5jDgTUayU5wk8hnQj4= =91by -END PGP SIGNATURE- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C/C++ 'assert' should not be used in R packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Duncan Murdoch wrote: On 10/11/2007 1:00 PM, Duncan Temple Lang wrote: 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. 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. I am not sure why you think we need to discard the DLL. I don't think this is worth spending much time on other than to encourage you not to use FreeLibrary or its equivalents on other systems and to use the R mechanisms. However, just to clarify. The package author has asserted that it is no longer safe to run. run _what_ ? The R session? The computer? The object is important here. assert() typically means that something unexpected in that routine or in our case the sequence of calls from .C/.Call/... So to assume that the session is no longer safe seems to be a large leap from this particular invocation is unsafe to run to normal completion. As with most things, it is a matter of scope and a simple mechanism such as assert() leaves the intentions of the programmer unclear. But of course it should not terminate the R session. Nor should R package developers link to libraries that make call the C routine exit() as this too will terminate the R session. One can use techniques to mask such calls to exit() in some circumstances. They are shutting down R, and Brian finds that too extreme. What if we want to access variables and routines merely to find out the resulting state after the assert(). And it is not clear whether you mean any subsequent calculations or any subsequent calculations using code within this DLL might be unreliable. How could I know why a package author decided a shutdown is needed? It depends on the author. But regardless of that and the assumption that users will ignore this error, why would you want to call FreeLibrary? Since R has induced the DLL to be loaded either directly or indirectly, R holds a handle to the DLL. If you don't use R's cross-platform facilities for releasing the DLL (either at the R or C-level), you will corrupt the session, specifically in the list of assumed-live DLLs. As I said, I'd prefer a cross-platform solution. Duncan Murdoch D. We provide 'error': please do use it to return control to the user when your code misbehaves. Similarly 'exit' and 'abort' should never be used in R packages. Sometimes it is not under your control: I sometimes see an rgl failure at R: indirect_vertex_array.c:659: emit_DrawArrays_old: Assertion `elements_per_request = count' failed. that is coming from the Mesa GL libraries. I'd say that's a bug, either in Mesa GL or in rgl. If you can make it reproducible, I'll try to track it down. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHNgoJ9p/Jzwa2QP4RAkeQAJ0Y0sMwWmb0k0u+3YI2lPXwBklpFQCfbCbk sY72JmcqQ78DQClVxIJKoKU= =3ZzG -END PGP SIGNATURE- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C/C++ 'assert' should not be used in R packages
On Nov 10, 2007, at 1:05 PM, Duncan Murdoch wrote: On 10/11/2007 1:00 PM, Duncan Temple Lang wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. 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. I am not sure why you think we need to discard the DLL. The package author has asserted that it is no longer safe to run. They are shutting down R, and Brian finds that too extreme. Me too. A package should never intentionally close the R session. If it does, it is a very severe design bug in the package (IMHO). Anything you use assert for can be gracefully handled (as opposed to let's say a segfault), so there is no excuse for killing the whole process at all (deliberately wiping all user's work is rude to put it mildly). Even if it might be unsafe to run anything, I'd still want to attempt to save my data. Cheers, Simon What if we want to access variables and routines merely to find out the resulting state after the assert(). And it is not clear whether you mean any subsequent calculations or any subsequent calculations using code within this DLL might be unreliable. How could I know why a package author decided a shutdown is needed? It depends on the author. But regardless of that and the assumption that users will ignore this error, why would you want to call FreeLibrary? Since R has induced the DLL to be loaded either directly or indirectly, R holds a handle to the DLL. If you don't use R's cross-platform facilities for releasing the DLL (either at the R or C-level), you will corrupt the session, specifically in the list of assumed-live DLLs. As I said, I'd prefer a cross-platform solution. Duncan Murdoch D. We provide 'error': please do use it to return control to the user when your code misbehaves. Similarly 'exit' and 'abort' should never be used in R packages. Sometimes it is not under your control: I sometimes see an rgl failure at R: indirect_vertex_array.c:659: emit_DrawArrays_old: Assertion `elements_per_request = count' failed. that is coming from the Mesa GL libraries. I'd say that's a bug, either in Mesa GL or in rgl. If you can make it reproducible, I'll try to track it down. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHNfHA9p/Jzwa2QP4RAo2BAJkB5QaFLOW5fcR6QE9JSXpIWAcEUwCggMYK 2WBnl5jDgTUayU5wk8hnQj4= =91by -END PGP SIGNATURE- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C/C++ 'assert' should not be used in R packages
On 10/11/2007 4:27 PM, Simon Urbanek wrote: On Nov 10, 2007, at 1:05 PM, Duncan Murdoch wrote: On 10/11/2007 1:00 PM, Duncan Temple Lang wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. 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. I am not sure why you think we need to discard the DLL. The package author has asserted that it is no longer safe to run. They are shutting down R, and Brian finds that too extreme. Me too. A package should never intentionally close the R session. If it does, it is a very severe design bug in the package (IMHO). Anything you use assert for can be gracefully handled (as opposed to let's say a segfault), so there is no excuse for killing the whole process at all (deliberately wiping all user's work is rude to put it mildly). Even if it might be unsafe to run anything, I'd still want to attempt to save my data. Perhaps I use assert() differently than you, but the way I use it is to assert assumptions that I believe will always be true. If one of those assertions fails, it means that my program is operating in a way that I did not foresee. I can't recover gracefully from that, because at that point my basic assumptions about the program have been proven to be incorrect. I have no basis for reasoning. It is by definition a bug. Now, it's possible that this bug has corrupted R and it really would be best for the user to discard all his work, but I agree that's unlikely. That's why I proposed that R should offer a way to handle an assertion failure that limits the shutdown to just my package. I don't offer a guarantee that my work won't corrupt a user's data, but I do work hard to avoid that. Allowing my package to tell the user that it is now unsafe to use is one way to do so. That's what assert() is for. In a standalone program, an (uncaught) assertion failure will cause the RTL to shut down the process. I think R should support a version of that, but limit the shutdown to the package that has failed. The version of assert() that I put together for rgl this morning doesn't attempt to shut down rgl, because that's really something that R should be responsible for. All it does is issue a dire warning to the user. Offline, Brian mentioned that some packages use assert() for input validation. That's an incorrect use of it, and those packages should use error(), as Brian suggested. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C/C++ 'assert' should not be used in R packages
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: n0' 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
Re: [Rd] C/C++ 'assert' should not be used in R packages
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: n0' 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
Re: [Rd] C/C++ 'assert' should not be used in R packages
On Nov 10, 2007, at 5:38 PM, Duncan Murdoch wrote: On 10/11/2007 4:27 PM, Simon Urbanek wrote: On Nov 10, 2007, at 1:05 PM, Duncan Murdoch wrote: On 10/11/2007 1:00 PM, Duncan Temple Lang wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. 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. I am not sure why you think we need to discard the DLL. The package author has asserted that it is no longer safe to run. They are shutting down R, and Brian finds that too extreme. Me too. A package should never intentionally close the R session. If it does, it is a very severe design bug in the package (IMHO). Anything you use assert for can be gracefully handled (as opposed to let's say a segfault), so there is no excuse for killing the whole process at all (deliberately wiping all user's work is rude to put it mildly). Even if it might be unsafe to run anything, I'd still want to attempt to save my data. Perhaps I use assert() differently than you, but the way I use it is to assert assumptions that I believe will always be true. If one of those assertions fails, it means that my program is operating in a way that I did not foresee. I can't recover gracefully from that, because at that point my basic assumptions about the program have been proven to be incorrect. I have no basis for reasoning. It is by definition a bug. Now, it's possible that this bug has corrupted R and it really would be best for the user to discard all his work, but I agree that's unlikely. That's why I proposed that R should offer a way to handle an assertion failure that limits the shutdown to just my package. I don't offer a guarantee that my work won't corrupt a user's data, but I do work hard to avoid that. Allowing my package to tell the user that it is now unsafe to use is one way to do so. I agree with everything so far... That's what assert() is for. No, that's the part I don't agree with. assert() is for a stand-alone program, not for modules. Using assert takes down whole R despite the fact that R itself is highly likely fine. It's the same as if you proposed that an error in a program should take the whole OS down, because you want to really alert the user. (I know, some OSes really do this, but not the ones I'd want to use ... :P) In a standalone program, an (uncaught) assertion failure will cause the RTL to shut down the process. I think R should support a version of that, but limit the shutdown to the package that has failed. The version of assert() that I put together for rgl this morning doesn't attempt to shut down rgl, because that's really something that R should be responsible for. All it does is issue a dire warning to the user. Again, I fully agree with that. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
