W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2007

[whatwg] SQL API error handling

From: Brady Eidson <beidson@apple.com>
Date: Tue, 16 Oct 2007 12:20:49 -0700
Message-ID: <0AD357C1-1A08-4D1D-879F-EF75257FB140@apple.com>

On Oct 16, 2007, at 11:29 AM, Geoffrey Garen wrote:

>> perhaps it would be prudent to change the spec to at least suggest  
>> that if a database becomes "known to be corrupt," operations on all  
>> open handles to that database should start throwing  
>> INVALID_STATE_ERR exceptions.
> I think this is already specified:
> 3. If transaction has been marked as "bad", then raise an  
> INVALID_STATE_ERR exception.
> ...
> 7. If the statement execution fails for some reason, transaction  
> must be rolled back and marked as "bad".
> I think you can reasonably consider a statement on a corrupt  
> database to have "failed for some reason."

After all active transactions are cleared, there is no context that  
remembers that the database is corrupt, and the next statement to be  
run would actually attempt to be executed.

I suppose user agents can volunteer to remember this and automatically  
fail the next statement, but it's certainly not specified.

Received on Tuesday, 16 October 2007 12:20:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:37 UTC