[whatwg] SQL API error handling

[Brady Eidson]

On Oct 16, 2007, at 2:08 PM, Geoffrey Garen wrote:

>> 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.
>
> Are you proposing that, once a database has been corrupted, all  
> transactions executed on it should fail, raising an  
> INVALID_STATE_ERR exception, for all time?

No, I was proposing that once a database has been corrupted, all  
transactions executed on it should fail, raising an INVALID_STATE_ERR  
exception, until the corruption is resolved.  But my intentions have  
changed (read below)

> Once all active transactions are cleared, there's no need to  
> remember that the database was corrupt. The user agent should simply  
> recover from the corruption in an implementation-defined way --  
> either by deleting the database, performing an error-recovering  
> integrity check, asking the user to install cosmic ray shielding  
> around the house, or something else.

This is great and all, and I suspect its what most user agents would  
do.  "Nuke the database from orbit," and all.  My concern is about any  
already-open-database handles.

INVALID_STATE_ERR is already overloaded and I think the corruption  
case is a particularly problematic one - I guess what I'm after is a  
special condition for the corruption case built in to the spec.

Say corruption is detected and we present this error to the script  
somehow - an exception for example.  Then we nuke the database and  
recreate it from scratch.  Unless the error we presented to the script  
was explicit about the condition, the script might not know that we  
just deleted the entire database and it is now empty.  They might  
execute some query that will succeed on the new, fresh database and  
they didn't even realize we reset the database behind their back.   
They might think that some cached data they have in memory is still  
persistent in the database, instead of knowing they could recover a  
little by writing it back out.

It would be nice to have a way to indicate to the script "There was a  
catastrophic event and we reset your database, assume you're starting  
over from scratch."

~Brady