W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2007

[whatwg] SQL API - SQLTransactionErrorCallback

From: Brady Eidson <beidson@apple.com>
Date: Mon, 29 Oct 2007 18:37:58 -0700
Message-ID: <26D82779-BB1D-4867-87C2-09031CAC8496@apple.com>

On Oct 29, 2007, at 6:25 PM, Ian Hickson wrote:

> On Mon, 29 Oct 2007, Brady Eidson wrote:
>>>> I propose we change SQLTransactionErrorCallback.handleEvent() to
>>>> have the same signature as the SQLStatementErrorCallback, which is:
>>>> boolean handleEvent(in SQLTransaction transaction, in SQLError
>>>> error);
>>> Actually I specifically didn't include the transaction because I  
>>> can't
>>> see what you could do with it. You know which transaction it is,  
>>> it's
>>> the one to which you are passing the method.
>> Why can't a developer have a global transaction error callback they  
>> use
>> for multiple transactions, including the possibility of transactions
>> from more than one database at a time?  No rule prevents this.
> They can, but so what? What are they going to do with the transaction
> object? It doesn't have any information they can use, and the only  
> method
> on there is one that would raise an exception if they called it.
> If the author wants to pass context information to their error handler
> they can (only) do so using currying, I don't see how the  
> SQLTransaction
> object is going to help them.

I agree that other than *being* the context information, the  
SQLTransaction object itself won't help them.
Since currying is a functional - if not annoying - solution, I'll let  
this one go  :)

Received on Monday, 29 October 2007 18:37:58 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:58 UTC