[whatwg] Should closeTransaction() be removed?

[Aaron Boodman]

I'm still not convinced that closeTransaction() is worth the trouble.
As I understand it, it is only used in cases where there was a
database error. The idea is that you check to see if there was an
error (with resultset.errorCode) and if so, call closeTransaction().
After that, you can call executeSql() again. If you don't call
closeTransaction(), calls to executeSql() after an error in the same
tx will throw.

My point of view is that database errors are rare and unexpected and
will be handled with a separate code path from the success path. In
simple cases, they need not be handled at all, throwing a global error
(which goes to window.onerror, then the error console) is sufficient.
In more complex cases, the db transaction may have been part of a
larger operation, like synchronization, which needs to be aborted and
handled gracefully in the UI. Still, in that case, the code for
handling errors is totally different than the code for handling
success, and it definitely does not need to do anything inside the
failed transaction.

Therefore, I propose the closeTransaction() method be removed, and the
executeSql() signature be changed to:

executeSql(stmt, opt_args, opt_callback, opt_errback);

Example:

executeSql("insert into customers (?)", ["bob"], function(rs) {
  executeSql("insert into receivables (from) values (?)",
[rs.insertedRowId], null, handleError);
}, handleError);

function handleError(e) {
  alert("database error: " + e.toString());
}

If executeSql() fails, the transaction is immediately rolled back and
opt_errback is called if it was specified.

If opt_errback was not specified, then a global error is thrown,
equivalent to what happens when you run window.setTimeout("throw new
Error('hello')").

- a