db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Re: Unexplained diff in procedureInTrigger.sql for JDK 1.6
Date Wed, 02 Aug 2006 00:15:25 GMT
Now that I think of it further, I suspect it is not good practice to 
hold a test hostage waiting for this bug to be fixed, and I should 
probably add a jdk16-specific master file for procedureInTrigger.sql.

I can point the reader of the bug to this master file as a guide to 
reproducing the problem...

Any thoughts?  Otherwise I'll go ahead and do that...

David

David Van Couvering wrote:
> Thanks, Dan, I concur, and thanks for your quick response.  I am going 
> to log it as a bug and not create a jdk16-specific master file for 
> procedureInTrigger.
> 
> I suspect when this bug is fixed a lot of jdk16-specific master files 
> will be out-of-date.  Personally, I am tired of fixing master files, as 
> the SQLException itch is turning into a bit of a rash :), so you may not 
> see my jump on fixing this bug...
> 
> David
> 
> Daniel John Debrunner wrote:
>> David Van Couvering wrote:
>>> Hi, all.  In evaluating diffs currently happening in JDK 1.6 derbyall, I
>>> ran across this strange diff:
>>>
>>> 398d397
>>> < ERROR 38000: The exception 'java.sql.SQLException: The external
>>> routine is not allowed to execute SQL statements.' was thrown while
>>> evaluating an expression.
>>>
>>> Basically what is happening is in JDK 1.6 Derby is not wrapping 38001
>>> inside 38000.  The reason?  Well, in JDK 1.6, Derby public methods
>>> throws SQLExceptions that are *not* a subclass of EmbedSQLException.
>>>
>>> This results in different logic in the method
>>> StandardException.unexpectedUserException():
>>>
>>>     public static StandardException unexpectedUserException(Throwable t)
>>>     {
>>>         /*
>>>         ** If we have a SQLException that isn't a Util
>>>         ** (i.e. it didn't come from cloudscape), then we check
>>>         ** to see if it is a valid user defined exception range
>>>         ** (38001-38XXX).  If so, then we convert it into a
>>>         ** StandardException without further ado.
>>>         */
>>>         if ((t instanceof SQLException) &&
>>>             !(t instanceof EmbedSQLException))
>>>         {
>>>             SQLException sqlex  = (SQLException)t;
>>>             String state = sqlex.getSQLState();
>>>             if ((state != null) &&
>>>                 (state.length() == 5) &&
>>>                 state.startsWith("38") &&
>>>                 !state.equals("38000"))
>>>             {
>>>                 StandardException se = new StandardException(state,
>>> sqlex.getMessage());
>>>                 if (sqlex.getNextException() != null)       
>>>                 {                       
>>> se.setNestedException(sqlex.getNextException());
>>>                 }
>>>                 return se;
>>>             }
>>>         }
>>>
>>> So, my question is, should I codify this by creating a jdk16 master file
>>> for procedureInTrigger.sql?  Or is this something we need to try and
>>> address?
>>
>> I think that's a bug. The comment indicates the code is determining if
>> the error was raised by Derby (nee Cloudscape), if so handle it
>> according to the SQL standard. The check for EmbedSQLException is no
>> longer sufficient with the JDBC 4 changes.
>>
>>
>> Dan.
>>

Mime
View raw message