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 :)
Thanks,
~Brady
