[whatwg] SQL API error handling

[Brady Eidson]

I don't feel quite passionately enough about this issue to pursue it  
with much more vigor, but will make one remaining point:

On Oct 17, 2007, at 6:58 PM, Ian Hickson 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?

Let's make the assumption that all User Agents are infallible.  There  
will never be a software bug in code that is specifically part of the  
browser that is exposed to the hosted application.  This is an  
unrealistic assumption, but lets make it for the sake of argument.

However, some things are outside of the user agent's complete control.

Say disk space, for example.  We just added an error code that means  
"the disk is full."  The disk is an external entity the user agent  
doesn't have complete control over, and therefore the user agent - and  
potentially applications it hosts - have to be ready to handle these  
external forces.

Corruption in the database isn't the fault of the user agent.  I  
consider it at the same level as corruption on disk - or even a full  
disk!
As I consider these to be similar, I assert that database corruption  
is an external force the user agent - and potentially the application  
it hosts - needs to be ready to handle.

There's a line between the user agent and application.  *Obviously*  
the user agent has to gracefully handle corruption, but I seem to be  
the only person on the side of the line where the hosted application  
gets to participate in handling the corruption case.

You've already alluded to a list of concerns for version 2 of the spec  
that can be addressed based on real world experience with version 1 in  
the wild.  Perhaps we can put this concern on the v2 list, and put  
this thread to rest.  ;)

Thanks,
~Brady