Re: Exceptions in WebDatabase

On Mon, 31 Aug 2009, Nikunj R. Mehta wrote:
>
> After studying the current error codes in the WebDatabase spec, it is 
> clear that they are neither an exhaustive, nor a systematic arrangement.

Indeed, they were added as needed.


> As a result, applications will have a hard time performing recovery with 
> or without user help.

That's not clear to me. As far as I can tell errors fall into two 
categories: those that are logic errors which need to be caught and fixed 
in development, and those that are environmental that you need to deal 
with in production. I agree that the errors aren't in any particularly 
good order that would make this distinguishable, but I don't really see 
that it matters -- you would just switch on the constants, not handle the 
numeric values themselves, surely.


> Here are my findings about the main categories of exceptions and their 
> causes:
> 
> Non transient exception - a retry of the same operation would fail 
> unless the cause of the SQLException is corrected
>
> Non transient connection exception - the connection operation that 
> failed will not succeed when the operation is retried without the cause 
> of the failure being corrected.
>
> Syntax error exception - in-progress query has violated SQL syntax 
> rules. Integrity constraint violation exception - an integrity 
> constraint (foreign key, primary key or unique key) has been violated.
>
> Data exception - indicates various data errors, including but not 
> limited to not-allowed conversion, division by 0 and invalid arguments 
> to functions.
>
> Feature not supported exception - UA does not support an optional 
> WebDatabase feature
>
> Serialization exception - an error with the serialization or 
> de-serialization of SQL types or with the size of the data being 
> returned
>
> Recoverable exception - a previously failed operation might be able to 
> succeed if the application performs some recovery steps and retries the 
> entire transaction
>
> Transient exception -  a previoulsy failed operation might be able to succeed
> when the operation is  retried without any intervention by application-level
> functionality.
>
> Timeout exception - the timeout has expired without obtaining necessary 
> locks.
>
> Transaction rollback exception - the current statement was automatically 
> rolled back by the database becuase of deadlock or other transaction 
> serialization failures.
>
> Of these exception conditions:
> 
> VERSION_ERR corresponds to the Non transient connection exception condition
> SYNTAX_ERR corresponds to the Syntax error exception condition
> CONSTRAINT_ERR corresponds to the Integrity constraint violation exception
> condition
> TOO_LARGE_ERR corresponds to the Serialization exception condition
> QUOTA_ERR corresponds to the Recoverable exception condition
> TIMEOUT_ERR corresponds to the timeout exception condition
> 
> On the other hand, the following errors say nothing about what the application
> can do:
> 
> UNKNOWN_ERR and DATABASE_ERR
> 
> Here is a proposal for error codes that allows better recovery for
> applications:
> 
> Constant, Code, description
> 
> NON_TRANSIENT_ERR, 1, cannot retry statement as is
> VERSION_ERR, 2
> SYNTAX_ERR, 3
> CONSTRAINT_ERR, 4
> DATA_ERR, 5
> FEATURE_ERR, 6
> SERIAL_ERR, 11, change something about the size of the result set to continue
> TOO_LARGE_ERR, 12
> RECOVERABLE_ERR, 21, retry after taking some user action
> QUOTA_ERR, 22
> TRANSIENT_ERR, 31, retry after some time, without needing any user action
> TIMEOUT_ERR, 32
>
> Since the UNKNOWN_ERR is unrelated to the database itself, I think we can
> leave it unchanged. I do think that either DATABASE_ERR has to clearly state
> the kind of problem that occurred, or else
> 
> Since the error codes in SQLException are local to WebDatabase, we would need
> an additional state variable in the SQLException exception that would identify
> the kind of problem encountered in the implementation. XOPEN and SQL:2003
> provide a full scheme of identifiers that can be used for such reporting,
> which is needed in applications so that appropriate action can be taken.
> 
> Based on both the above points, here's a proposed IDL for SQLException
> 
> exception SQLException {
>   const unsigned short UNKNOWN_ERR = 0;
>   const unsigned short NON_TRANSIENT_ERR = 1;
>   const unsigned short VERSION_ERR = 2;
>   const unsigned short SYNTAX_ERR = 3;
>   const unsigned short CONSTRAINT_ERR = 4;
>   const unsigned short DATA_ERR = 5;
>   const unsigned short FEATURE_ERR = 6;
>   const unsigned short SERIAL_ERR = 11;
>   const unsigned short TOO_LARGE_ERR = 12;
>   const unsigned short RECOVERABLE_ERR = 21;
>   const unsigned short QUOTA_ERR = 22;
>   const unsigned short TRANSIENT_ERR = 31;
>   const unsigned short TIMEOUT_ERR = 32;
>   unsigned short code;
>   DOMString sqlState;
>   DOMString message;
> };

I'm not convinced this is an improvement.

It boils down to adding some generic codes that will never be fired, 
unless I misunderstand the proposal, and adding two codes that are, as far 
as I can tell, unnecessary (DATA_ERR and FEATURE_ERR).

I think it would be more useful to examine this from the perspective of 
use cases. We should examine sample code that uses the API and see what 
problems exist in practice, rather than try to determine the ideal error 
codes from theory.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 26 November 2009 02:33:35 UTC