Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

HTML5 Database - transaction VS executeSql callbacks order

talking about HTML5 database (sqlite), I've recently used success/error callbacks from both transaction and executeSql functions. I found out that for these two functions, the success/error callback order is reversed, for example:

transaction

database.transaction(function(tx){
    //--- do something
}, function(){
    //--- error handling
}, function(){
    //--- success handling
});

executeSql

tx.executeSql(sqlStatement, [], successCallback, errorCallback);

Probably it's not an important thing to know, but I'd like to know if there's a reason for this reversed order.. IMHO, it would be useful to have the same callback order for each function, so as you learned how to use one, you know how all the others work!

Thanks in advance, regards

like image 607
BeNdErR Avatar asked Jun 24 '13 07:06

BeNdErR


1 Answers

I'm referring here to [the main RFC document]: and it's worth noting that

This specification is no longer in active maintenance and the Web Applications Working Group does not intend to maintain it further.

Nonetheless, back to the question. The reasoning behind this may be buried in the archives of the discussion mailing lists

I can reason on how people usually build an API.

First thing to note is that the various callback arguments of both functions are optional, so you want to order them from the most used to the least used. If you put it in the opposite order you force people to declare empty functions.

So, in a Transaction, error handling is more important than success handling. Transactions are "designed" to fail gracefully, and extremely important because we expect them to fail from time to time and to handle their failure.

On the contrary, a query should return its results, without failing too much. While, when we have success, and this should happen really often we want to process the result of such query, and this is when you use the SQLStatementCallback callback which is not a SQLVoidCallback successCallback. This callback is not for handling success, but for explicitly handling statements results (i.e., to process the results).

Compare the transaction and the executeSql declarations here.

like image 116
Kuzeko Avatar answered Nov 13 '22 13:11

Kuzeko