Well I think the distinction here is that Hibernate constitutes a "hard" dependency on Antlr. The users choice to use Oracle is completely within their control.
-----Original Message----- From: Max Andersen Sent: Wednesday, February 08, 2006 8:41 AM To: Steve Ebersole; Scott M Stark; jboss-development@lists.sourceforge.net; Hibernate development Subject: Re: [Hibernate] Do antlr exception leak to users? 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&kid3432&bid#0486&dat1642 _______________________________________________ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
