Hi,
antlr exceptions can probably be "contained" by some of the methods
mentioned below - no problem.
I'm just wondering what to do with other exceptions ? They will have the
same/similar problem correct? e.g. a ocracle driver specific exception
occurs
which is pretty good to have as the cause...that will spill to other
clients too.
/max
The thing that we discussed (and I have just not yet had time to
implement) is actually converting QueryExceptions that contain antlr
stuff during serialization by either writeReplace() or writeObject().
Initially we had discussed just stripping the cause in the case of antrl
exception, but perhaps another option is to simply write a replacement
for the antlr exception during writeObject() on the QueryException.
Yet another option would be to handle this as we recognize antrl
exceptions in the translator/parser and "decompose" that information. I
don't think the stack trace of the antlr exceptions themselves are
really that vital to users anyway so we could just log the antlr
exceptions for debug purposes.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Max
Rydahl Andersen
Sent: Tuesday, February 07, 2006 2:02 PM
To: Scott M Stark; jboss-development@lists.sourceforge.net; Hibernate
development
Subject: Re: [Hibernate] Do antlr exception leak to users?
On Tue, 07 Feb 2006 20:55:52 +0100, Scott M Stark
<[EMAIL PROTECTED]>
wrote:
fixing the antlr exception svuid won't help us if the client
is using an older version, right ?
It will if the serialVersionUID is set to the implicit value from the
previous version. This can be done if the version is still
serializable
compatible.
which it isn't afaik. the antlr version started to include more data in
the exception over time.
calling printStackTrace() on every exception sounds overkill
for me...and will turn basic logging into something very verbose.
Should be no different from now as logging generally includes the
cause.
well, for me that is showing the exception message in a dialog in the ui
I
would be very
disappointed to have a full stack trace in the message output.
I understand the issue, but don't find the suggested
solutions any good ;(
Would be nice to have an option to have any exposed remote
exception do the serialization of the "cause".
Would make it a non-issue where it actually matters.
This can't be done without modifying the exception either via source
or
bytecode manipulation.
And bytecode manipulation or simple modification of the exception in the
jboss serialization/remoting layer
have that option, correct ?
--
--
Max Rydahl Andersen
callto://max.rydahl.andersen
Hibernate
[EMAIL PROTECTED]
http://hibernate.org
JBoss Inc
[EMAIL PROTECTED]
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
