Exceptions in WebDatabase

After studying the current error codes in the WebDatabase spec, it is  
clear that they are neither an exhaustive, nor a systematic  
arrangement. As a result, applications will have a hard time  
performing recovery with or without user help. To improve on this, I  
analyzed the JDBC SQL exception hierarchy and matched it against the  
WebDatabase spec.

Here are my findings about the main categories of exceptions and their  

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  
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  
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:


Here is a proposal for error codes that allows better recovery for  

Constant, Code, description

NON_TRANSIENT_ERR, 1, cannot retry statement as is
SERIAL_ERR, 11, change something about the size of the result set to  
RECOVERABLE_ERR, 21, retry after taking some user action
TRANSIENT_ERR, 31, retry after some time, without needing any user  

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;

Received on Monday, 31 August 2009 21:37:30 UTC