[ 
https://issues.apache.org/jira/browse/DERBY-6488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13908296#comment-13908296
 ] 

Knut Anders Hatlen commented on DERBY-6488:
-------------------------------------------

Some exceptions generated high up in the JDBC layer don't have a 
StandardException in their chain, so the network server doesn't have a way to 
get the message id of these exceptions currently if we eliminate 
EmbedSQLException from the chain. The code that generates those exceptions 
already depends on StandardException (for example, it uses methods such as 
StandardException.getSeverityFromIdentifier() when building the 
EmbedSQLException), so I don't think just replacing EmbedSQLException with 
StandardException in those exceptions would introduce any new intermodular 
dependencies.

> Get rid of the EmbedSQLException class
> --------------------------------------
>
>                 Key: DERBY-6488
>                 URL: https://issues.apache.org/jira/browse/DERBY-6488
>             Project: Derby
>          Issue Type: Improvement
>          Components: JDBC
>    Affects Versions: 10.11.0.0
>            Reporter: Knut Anders Hatlen
>
> EmbedSQLException used to be the top-level exception raised on error in the 
> JDBC 3 version of the embedded driver. The primary purpose of the 
> EmbedSQLException class is gone now that JDBC 4.0 is the minimum JDBC level, 
> and all top-level exceptions are vanilla java.sql.SQLExceptions or one of its 
> specialized subtypes.
> The top-level SQLException still links to an EmbedSQLException in order to 
> provide some extra information (such as the message id) that the network 
> server needs when encoding the exception for transport over the wire. I think 
> it should be possible for the network server to get this information from the 
> StandardException which is typically also in the exception chain.
> When embedded Derby raises an exception currently, it is typically a 
> java.sql.SQLException (or subclass) that's linked to an EmbedSQLException 
> that's linked to a StandardException. If we could find a way to eliminate the 
> EmbedSQLException from the exception chain, the stack traces would be easier 
> to read, and the structure of the exception chains would be more consistent 
> with the client exceptions.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Reply via email to