[whatwg] SQL API error handling

[Scott Hess]

On 9/24/07, Ian Hickson <ian at hixie.ch> wrote:
> On Thu, 20 Sep 2007, Anne van Kesteren wrote:
> > The SQL API doesn't seem to define how to deal with errors, such as:
<snip>
> >  * Database that is full
>
> This currently just reports an error with code 1, like everything else,
> but in due course we should get a useful set of error codes and define
> them. I'd love implementation feedback on what errors they are actually
> going to naturally end up wanting to report.

In most database clients, errors can be separated into:

 - Things that the client can do something about.
 - Things that it cannot do anything about.

In the first case, since we're working within the browser, there's
generally really nothing to be done, so most stuff falls to the second
case.  At that point, it would be useful to have a human-readable
error string generated by the library which can be logged, for
debugging purposes.

Reviewing SQLite's error list, the things that MAY have utility to
report more finely might be:

 * LOCKED, where you failed because someone else has things locked.
Presumably if a single thread of control tries to open the same
database via two objects and start two transactions, one of them is
going to lose.  Having a transaction fail for this reason seems
materially different from having it fail because the SQL was invalid
or something of that nature, because the appropriate response might be
to retry.

 * CORRUPT, insofar as the Database API lets you delete databases (it
doesn't currently, but we've thought of adding that to Gears).

-scott