[R-sig-DB] Add a "dbSendUpdate" function to DBI?
Paul Gilbert
pg||bert902 @end|ng |rom gm@||@com
Thu Sep 4 20:23:53 CEST 2014
On 09/04/2014 12:26 PM, Hadley Wickham wrote:
>> 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("!!"))
It is the "If the API" part that I worry about. For example
> success(warning("warn"))
Warning message:
In doTryCatch(return(expr), name, parentenv, handler) : warn
> is.logical(success(warning("warn")))
[1] FALSE
Warning message:
In doTryCatch(return(expr), name, parentenv, handler) : warn
>
So then every package writer trying to build on DBI has to write a
wrapper that anticipates the exceptions that may be thrown. This becomes
even more difficult when different db drivers, different OSes, and
different servers are involved.
Given the philosophical constraint I think I would generally prefer the
function that is guaranteed to return a logical. The other wrapper is
easy to write too.
Paul
>
> Hadley
>
More information about the R-sig-DB
mailing list