db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance J. Andersen" <Lance.Ander...@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:46:33 GMT
Sorry it was not a question, i was commenting that the SQLState might be 
a better way then the error code today to understand the error, your 
milage might vary though driver to driver.  Error handling is definitely 
not pretty today in JDBC from a portability point of view



David W. Van Couvering wrote:

> 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