On Wed, Jun 18, 2014 at 8:05 PM, Dirk Eddelbuettel <e...@debian.org> wrote:
> > On 18 June 2014 at 19:40, Tim Keitt wrote: > | > | > | > | On Wed, Jun 18, 2014 at 6:26 PM, Dirk Eddelbuettel <e...@debian.org> > wrote: > | > | > | Tim, > | > | Step back for a second and recognise that everything happens via > | > | SEXP .Call(SEXP a, SEXP b, ...) > | > | where R calls your C++ routine asynchronously. > | > | You can do tricks _within the subroutine that is called_ which is > | essentially > | what happens via the automatically-added try/catch block we have in > C++. > | And > | Rcpp::stop() is just a shortcut for using those. > | > | > | Can I throw a condition (meaning an object inheriting class "condition") > or am > | I limited to strings? If I throw a condition, will it be raised as such? > > See eg Section 2.7 titled "Exception Handling" in my Springer book on Rcpp. > This is standard stuff, and we discussed the basics in the 2011 JSS paper. > > You can throw anything that is subclassed from std::exception, and catch it > appropriately. The default mechanism is to take the exception text and > pass > it to R -- because, once again, passing a string is all we can do. _Your_ > code could course provide more complex things and keep them, and tickle (by > error codes) retrieval via other functions. > > But again, the interface we are given by R is fixed. You can only be > creative within the confines of that interface. > > Got it. Decided exceptions are evil and tore it out. Easy to return a status string. THK > Dirk > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > -- http://www.keittlab.org/
_______________________________________________ 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
