db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-254) SQLStates for SQLExceptions thrown from the client should not be null and should match embedded where possible
Date Wed, 05 Oct 2005 21:41:12 GMT
I'm not sure I understand your question, but yes, as part of the work on 
internationalizing the SQL Exception messages I am also making sure the 
exceptions return a useful SQL State.  Where the exception is identical 
with an exception already thrown on the embedded driver, I'm going to 
use the same SQL State.  For exceptions that are unique to the client 
driver, I'm going to create new SQL States using the existing SQL State 
class for Derby JDBC errors, XJ0.

David

Lance J. Andersen wrote:
> What about the SQLStates that are returned?  Some SQL State Class values 
> might be appropriate.  Yes JDBC 4 will help somewhat
> 
> lance
> 
> Kathey Marsden wrote:
> 
>>Daniel John Debrunner wrote:
>>
>>  
>>
>>>Kathey Marsden wrote:
>>>
>>>
>>> 
>>>
>>>    
>>>
>>>>>Daniel John Debrunner commented on DERBY-254:
>>>>>---------------------------------------------
>>>>>     
>>>>>
>>>>>        
>>>>>
>>> 
>>>
>>>    
>>>
>>>>>I'm not sure Derby should be recommending checking the error code for
an exception, I don't think today it's specified as any part of the documentation that the
error code is a severity. Use of the error code is vendor specific and will result in non-portable
programs. JDBC 4.0 is addressing this with the sub-classing of SQLException.
>>>>>
>>>>>
>>>>>
>>>>>     
>>>>>
>>>>>        
>>>>>
>>>>So with the product as is, (before JDBC 4.0) what is the recommended way
>>>>to check if an exception makes a connection invalid.  Currently I know
>>>>there are users that are using the error codes (Exception Severity)?
>>>>   
>>>>
>>>>      
>>>>
>>>Execute a simple statement against the connection, e.g. VALUES 1.
>>> 
>>>
>>>Is the severity error code even portable between embedded and the client
>>>driver?
>>> 
>>>
>>>    
>>>
>>Sadly, the  client uses different numbers for the same  meaning ,  (I
>>won't even mention what those numbers are!)
>>
>>So, the take home for me is.
>>
>>1) There is not really an efficient way to do this for JDBC3.0 but
>>JDBC4.0 will be better.
>>2) We don't want folks to use those error codes at all.
>>
>>Moving forward  I think we should
>>1) Encourage those folks that are using the error codes to stop.
>>2) Not change  the error codes.  Since we don't want to publish them,
>>there seems no point in changing them to anything.
>>
>>
>>Kathey
>>
>>
>>
>>  
>>

Mime
View raw message