[whatwg] SQL API error handling

[Brady Eidson]

On Oct 15, 2007, at 8:37 PM, Ian Hickson wrote:
>>>> * CORRUPT, insofar as the Database API lets you delete databases  
>>>> (it
>>>> doesn't currently, but we've thought of adding that to Gears).
>>
>> You may be correct that authors shouldn't be dealing with this.
>> Guaranteeing the integrity of the database at open is prohibitive  
>> (you
>> may have to scan the entire database), and no guarantee in  
>> practice, so
>> it's possible that you can detect corruption at any arbitrary  
>> statement.
>
> Sure, but that problem occurs everywhere. I mean, there's no JS  
> exception
> for "your CPU core just overheated", but we don't guarentee that won't
> happen either. Database corruption will occur either for hardware  
> reasons
> or due to software bugs. Hardware failures could cause all kinds of  
> random
> stuff, including software bugs (through corruption of executables).  
> Having
> an API to handle software bugs seems silly, since if we could assume  
> that
> that API was bug free, why not assume the rest of the API is too. This
> just seems like a case we shouldn't worry about.


I agree with your principals here, but think databases are a different  
story.  In some embedded (and client-server) database implementations  
- including SQLite - continuing to operate on a database that is known  
to be corrupt can lead to the process crashing.  Unlike the "CPU core  
just overheated" case, it is a dangerous state software can help avoid.

How the user agent handles the problem long term (ask the user what to  
do, silently delete and recreate it, let the database continue to be  
corrupt, etc) may not need to be specified, but 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.

Thanks,
~Brady