[whatwg] SQL API error handling

[Scott Hess]

On 10/17/07, Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 15 Oct 2007, Brady Eidson wrote:
> > 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.
>
> Ok... but why can't the software simply avoid corrupting the database in
> the first place?
>
> We don't have error codes for "the DOM has become corrupted" or for "the
> Window object's properties have become corrupted", why do we need one for
> "the Database's contents are corrupted"? Why can't the database contents
> simply not be corrupted in the first place?

One difference is that the database is persistent.  If the DOM became
corrupted, and you refresh the page or restart the browser, there's a
good chance that your DOM will no longer be corrupted.  If your
Database is corrupted and you refresh the page or restart the browser,
your Database is still corrupted.

> On Tue, 16 Oct 2007, Scott Hess wrote:
> > I think that if the user agent did detect corruption and nuke the
> > database from orbit, then it would be reasonable for the user agent to
> > invalidate all outstanding database handles.  But that kind of thing
> > would seem to be something really beyond the spec to deal with.  It
> > seems like at that point the most appropriate action to take would be to
> > refresh the page and start from scratch, rather than expecting the app
> > to somehow handle the problem.
>
> I agree.

You almost need an "oncorruption" handler (or maybe something more
general).  Detecting that a database is corrupt from within an
individual statement's callback really isn't all that interesting,
there's nothing statement-specific that you'd want to do at that
point.  But your oncorruption handler could do things like delete the
corrupt database and the three other databases which no longer make
sense without it, and reload the page.  The default handler could just
delete the database in question.

-scott