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.
