- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 2 Feb 2010 00:53:56 +0000 (UTC)
- To: Dumitru Daniliuc <dumi@chromium.org>
- Cc: public-webapps <public-webapps@w3.org>
On Mon, 1 Feb 2010, Dumitru Daniliuc wrote: > > In section 4.3.2, point 6, the "In case of error..." paragraph says: > > 2. If the error callback returns false, then move on to the next statement, > if any, or onto the next overall step otherwise. > 3. Otherwise, the error callback did not return false, or there was no error > callback. Jump to the last step in the overall steps. > > I'm proposing the following change (the wording could be different, of > course): > > 2. If the error callback returns false *and the transaction is not in an > unrecoverable state*, then move on to the next statement, if any, or onto > the next overall step otherwise. > 3. Otherwise, if the error callback did not return false, or there was no > error callback, *or the transaction is an unrecoverable state*, jump to the > last step in the overall steps. > > This request is motivated by http://www.sqlite.org/c3ref/get_autocommit.html: > "If certain kinds of errors occur on a statement within a multi-statement > transaction (errors including > SQLITE_FULL<http://www.sqlite.org/c3ref/c_abort.html>, > SQLITE_IOERR <http://www.sqlite.org/c3ref/c_abort.html>, > SQLITE_NOMEM<http://www.sqlite.org/c3ref/c_abort.html>, > SQLITE_BUSY <http://www.sqlite.org/c3ref/c_abort.html>, and > SQLITE_INTERRUPT<http://www.sqlite.org/c3ref/c_abort.html>) > then the transaction might be rolled back automatically." If such an error > occurs, we cannot move on to the next statement as currently requested by > the spec. These fall under the general "User agents may impose implementation-specific limits on otherwise unconstrained inputs, e.g. to prevent denial of service attacks, to guard against running out of memory, or to work around platform-specific limitations." rule, under which you can basically do whatever you need to do to handle unexpected errors. If I edit the spec again, I'll make this more clear. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 2 February 2010 00:54:25 UTC