If I tweak your example package code so that all exceptions are caught via
a catch (...) {} block, I can see something like:> uptest::uptest() Error in (function () : Ouch from R Caught some other exception. The fact that we're still printing the R error message seems undesirable, but it looks like the exception can be caught -- just not via std::exception. On Sun, Feb 6, 2022 at 9:21 AM Kevin Ushey <kevinus...@gmail.com> wrote: > Is it possible the issue here is ultimately just that our > LongjumpException class doesn't inherit from std::exception? > > On Sun, Feb 6, 2022 at 9:18 AM Jeroen Ooms <jeroeno...@gmail.com> wrote: > >> On Sun, Feb 6, 2022 at 5:56 PM Dirk Eddelbuettel <e...@debian.org> wrote: >> > >> > >> > On 6 February 2022 at 17:40, Jeroen Ooms wrote: >> > | We can try to take V8 out of the equation, and see what actually >> > | causes the change. V8 uses (and tests!) the Rcpp feature to call an R >> > | function from C++. This behaves quite differently when using >> > | RCPP_UNWIND_PROTECT. >> > | >> > | Here is a dummy package to demonstrate this: >> https://github.com/jeroen/uptest >> > | >> > | The use case is simple: we want to call some R function from C++, and >> > | if it fails, catch the error message and deal with it in C++. I >> > | suspect there are more packages doing this, but perhaps they are not >> > | testing this case. >> > | >> > | The example from uptest above show that when we compile with >> > | RCPP_UNWIND_PROTECT, any R error is always printed directly to the >> > | console. Even if we catch the Rcpp::LongjumpException in C++, the R >> > | error still seems to bubble up (as Iñaki also noted). I think this is >> > | at least surprising. >> > | >> > | Then I am not sure what we do in C++ now with this >> > | Rcpp::LongjumpException if we catch it. We certainly don't want to >> > | unwind all the way in the middle of running the javascript code. The >> > | JavaScript code should be able to catch the R error, and continue >> > | running the script. >> > | >> > | Anyway if you want to make RCPP_UNWIND_PROTECT the default, I can >> > | obviously opt-out in V8, but as an Rcpp user I am not convinced this >> > | is an improvement. >> > >> > Thanks for the feedback. I think there is an easy-to-understand, >> easy-to-make >> > error in a sample package (but kudos for creating one!). Because Rcpp >> will >> > always wrap try/catch around the function you create with its >> mechanism, the >> > layer inside is redundant. So I suggest the C++ function file becomes >> this >> > simpler / shorter variant: >> > >> > #include <Rcpp.h> >> > using namespace Rcpp; >> > >> > // [[Rcpp::export]] >> > Rcpp::NumericVector call_r_from_rcpp() { >> > Rcpp::Function callback = >> Rcpp::Environment::namespace_env("uptest")["callback"]; >> > callback(); >> > return Rcpp::NumericVector::create(42); >> > } >> > >> > which behaves fine for me in both cases. >> >> Well not really, this kind of misses my point that it the >> unwind-protect makes it impossible to meaningfully catch the R error >> in C++, handle it, and continue running the C++ code, without aborting >> the entire mission and throwing the user back in the console. >> _______________________________________________ >> Rcpp-devel mailing list >> Rcpp-devel@lists.r-forge.r-project.org >> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel > >
_______________________________________________ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
