[whatwg] Question on handling of failed statements in database API

[Aaron Boodman]

Hi all,

Quick request for clarification on how to handle failed statements.
The spec says (4.11.6 - step 12):

Call the error callback with a newly constructed SQLError object that
represents the last error to have occured in this transaction. If the
error callback returned false, and the last error wasn't itself a
failure when committing the transaction, then try to commit the
transaction. If that fails, or if the callback couldn't be called
(e.g. the method was called with only one argument), or if it didn't
return false, then rollback the transaction. Any still-pending
statements in the transaction are discarded.

So let's say:
- a statement fails
- we call the statement error handler, and it does not return false
- we call the transaction error handler, and it returns false
- we attempt to commit, and the commit fails

It seems like at this point, the proposal says that we should just
silently fail. (That is, don't call the transaction failure callback
again). It seems like this loses information. The commit may fail for
some other reason that why the statement failed.

What do people think of changing the proposal to remove
SQLTransactionErrorCallback's return value. It seems like whatever
you'd want to do with it, you could do with SQLStatementErrorCallback.
Granted, you might have to have an error callback for every statement,
but I feel like ignoring failed statements is kinda an edge case.

- a