[R-sig-DB] Add a "dbSendUpdate" function to DBI?

[Paul Gilbert]

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
>