db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dibyendu Majumdar <dibye...@mazumdar.demon.co.uk>
Subject Derby Exception classes
Date Fri, 29 Feb 2008 00:33:11 GMT
Hi,

There have been some suggestions from Dan and Knut that  
EmbedSQLException and StandardException should be removed in favour  
of SQLException.
I am interested in this because at present, the way these and other  
related exception classes are managed causes undesirable interactions  
between modules. For instance, classes from o.a.d.impl.jdbc get  
called from modules other than o.a.d.iapi.jdbc.

Part of the problem I think is that some of the Exception classes add  
additional attributes, that are not part the standard Java library  
classes.
For instance, the messageId attribute in StandardException.
Or the array of arbitrary arguments.

Replacing StandardException or EmbedSQLException with SQLException  
will cause information to be lost.

I have been thinking about some possible ways of overcoming the  
issues and would like feedback.
Some of the fields such as messageId, report, and severity in  
StandardException can be encoded in the vendorCode field in  
SQLException.
Instead of storing a text messageId, we can store a unique number  
that is then mapped to the string - the integer value could be the  
offset to an array of Strings.
The report and severity fields can be combined with the messageId  
value by ORing numeric values.

The bigger issue is with the array of arguments. There seems to be no  
way of retaining these. Any thoughts?

Regards

Dibyendu

Extract from DERBY-3451:

 > The main reason originally for EmbedSQLException originally was to  
be able to
 > keep the original non-SQLException (e.g. StandardException,  
IOException), which is (should be?) now handled by  
Throwable.initClause().

Another reason for EmbedSQLException is to be able to keep the  
message id so that we can localize the messages correctly on the  
network client. I haven't seen any proposals for how to solve that  
issue yet. (That's why we create the argument ferry (an  
EmbedSQLException) in the JDBC 4.0 exception factory.)

 > Throwing a non-java library exception causes some issues for JMX  
as the exception can not be transfered to the client.

Solving this problem involves getting rid of StandardException too,  
doesn't it? At least when the SQLException is linked to a  
StandardException.
Mime
View raw message