[whatwg] SQL API error handling

[Brady Eidson]

On Oct 16, 2007, at 4:04 PM, Geoffrey Garen wrote:

>> 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."
>
> In general, I'm not sure how useful it is to know that you're  
> "starting over from scratch," since any database query needs to  
> check its result. Presumably, an app's behavior in the "no data"  
> case is the same regardless of *why* there's no data. 99% of the  
> time the behavior will be to reload the data from a server.
>
> More importantly, what constitutes a corrupt database, and how to  
> recover from it, are serious implementation details. Some  
> implementations may have error correction algorithms. Others may  
> have backups they can restore. Others may have to wipe the database  
> completely and start over. Still others may not be able to start  
> anything. (For example, the storage medium might have gone bad, or  
> been locked or disconnected.) So, imposing a "start over from  
> scratch" requirement would hamper some implementations while  
> requiring the impossible of others.

You are (rightly) reading very specifically into what I am saying,  
whereas what I'm trying to get at is still vague and general.

Let me take a step back and try to frame it at a higher level

- A page opens a valid database handle.
- Some script uses that database handle - successfully
- Some external event happens on the client machine - database  
corruption, the user deletes the database from the user agent's  
"database management mode", gamma rays corrupt a single bit on the  
disk, or whatever.  This event renders the database unusable.
- Some action is taken to reset the database so that it is usable -  
lets pretend the resolution is always recreating an empty database  
from scratch
- The script knows something wrong happened - it has a completely 100%  
generic error on its query.  But it is unaware of the nature of this  
event and its resolution.  It decides to execute a new sql statement,  
and the value of this statement (from the script's perspective) is  
reliant on previously established values in the database.  The  
statement coincidentally succeeds even with the new empty database.

For further argument, lets pretend the script is in an onunload  
handler and its writing some small piece of data out to the database  
before the user "quits".  It has a lot of other data in memory client- 
side that it *thinks* is in the database, but really isn't anymore.   
It *could* write this data out, preserving a lot of important user  
state.  But it doesn't know to do so.

One can certainly make the argument that if this were a native  
application saving data to disk, it would be prudent to verify its  
data on disk.
But I think "raw filesystem" and "database" are different paradigms  
with different usage expectations.
An error code along the lines of "your database was just reset" might  
fit the bill.  This could be because of corruption, because the user  
agent database management was invoked and the database cleared, or a  
number of other reasons.

This is a requested split from code 1 - "The statement failed for  
reasons not covered by any other code."

~Brady