> I think this depends on the code. There are frequently situations where it
> is nice to have a function that is certain to return a logical value, so not
> have to catch exceptions and parse for all possibilities. (BTW, if error
> message text is to be returned then that can be set as an attribute to the
> logical value.) My feeling is it would be nice to have both, one function
> certain to return a logical, and one that will throw an error. If one is a
> simple wrapper to the other then only one method needs to be implemented and
> the DBI default can look after the other.
I think this is a philosophical API design decision, and it's a bad
idea to try and support both approaches. That makes it confusing how
you should approach a problem and more likely that you fail to catch
an important error.
If the API returns TRUE or throws an error, it's easy to write your
own wrapper to make it return TRUE or FALSE:
success <- function(x) {
tryCatch(x, error = function(e) FALSE)
}
success(TRUE)
success(stop("!!"))
Hadley
--
http://had.co.nz/
_______________________________________________
R-sig-DB mailing list -- R Special Interest Group
R-sig-DB@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-db
