There is a request from the eXist group that we remove the final modifier=
on=20
XMLDBException so that they could use subclasses of XMLDBException in ord=
er=20
to get clearer stacktraces. Below are some details of the conversations o=
n=20
the list:
_______________________
> I have noticed a lot of code like:
>
> } catch (Exception e) {
> throw new XMLDBException( blah, e.getMessage() );
> }
>
> which is really hard to work with when debugging, as most of
> the information about the exception is lost.
>
> Has use of a cascading exception class been considered? Something
> like Avalon's CascadingException and CascadingRuntimeException?
> I'm kinda tearing my hair out tonight trying to track down a class
> loader problem, and would LOVE to be able to see my stack traces!
_______________________
> The only thing we can do is to remove the final and ask the XMLDB maili=
ng=20
> list to change it in the CVS. I don't see another possibility to improv=
e the=20
> exception handling. Does Java check the final at runtime or only at com=
pile=20
> time? If it just checks it at compile time, it would not be a problem i=
f=20
> people used an xmldb.jar from another source.
________________________
I understand that the intent is to use ErrorCodes and I guess the underla=
ying=20
reason for this has to do with IDL. Still if a certain implementation wan=
ts=20
to subclass XMLDBException for clarity I do not see how this would break =
the=20
intent of the API.=20
The proposal is to change=20
public final class XMLDBException extends Exception=20
to
public class XMLDBException extends Exception=20
Let me know what you think.
Best regards,
Per Nyfelt =20
----------------------------------------------------------------------
Post a message: mailto:[EMAIL PROTECTED]
Unsubscribe: mailto:[EMAIL PROTECTED]
Contact administrator: mailto:[EMAIL PROTECTED]
Read archived messages: http://archive.xmldb.org/
----------------------------------------------------------------------
