- From: Scott Hess <shess@google.com>
- Date: Fri, 5 Oct 2007 16:12:32 -0700
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
Received on Friday, 5 October 2007 16:12:32 UTC