The problem is the source of the cause not providing a stable api for
the exception, not the inclusion of the cause itself. The solution is to
fix the antlr exceptions to specify the serialVersionUID to avoid
trivial changes showing up as version incompatibilities.
You can always work around this by explicitly incorporating the cause
into the exception message string:
try
{
...
}
catch(Exception e)
{
StringWriter sw = new StringWriter();
PrintWriter pw = new PrintWriter();
pw.println("... cause:");
e.printStackTrace(pw);
pw.close();
String msg = sw.toString();
throw new Xception(msg);
}
> -----Original Message-----
> From: Max Andersen
> Sent: Tuesday, February 07, 2006 10:34 AM
> 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 19:24:38 +0100, Scott M Stark
> <[EMAIL PROTECTED]>
> wrote:
>
> > I'm a little concerned that this will lead to unnecessary
> coupling of
> > client and server versions of antlr then. How often does an antlr
> > exception as a cause show up in practise as an exception seen by an
> > external client?
>
> hmm..whenever a syntax error occur in a HQL/EJBQL statement.
>
> But how else can we provide the cause of an exception ?
> This is a pretty critical part of debugging hibernate applications.
> Not just for antlr exceptions, but jdbc driver exceptions,
> sqlexceptions and any other external "cause".
>
> /max
>
-------------------------------------------------------
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&kid3432&bid#0486&dat1642
_______________________________________________
hibernate-devel mailing list
hibernate-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hibernate-devel
