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