I disagree, use getCause(). Users should see the class as similar to the JDK as much as possible.
See http://jakarta.apache.org/commons/collections/apidocs-COLLECTIONS_3_1/org/ap ache/commons/collections/FunctorException.html http://cvs.apache.org/viewcvs.cgi/jakarta-commons/collections/src/java/org/a pache/commons/collections/FunctorException.java?rev=1.6&view=auto Stephen ----- Original Message ----- From: "Henri Yandell" <[EMAIL PROTECTED]> > Is using the same name as Throwable for getCause() wise? > > Won't this lead to times when you can compile on 1.3, and the code won't > run on 1.4? (unsure, but it seems likely to me). > > I'd suggest getThrowable as with Lang. You know it's supported by the > reflection Utils in Lang if someone puts them together, and it keeps > things standard. > > Hen > > On Fri, 9 Jul 2004, Mark R. Diggory wrote: > > > I suspect that would just look like this, is this adequate for our needs? > > > > -Mark > > > > /** > > * A generic exception indicating problems in the math package. > > * @version $Revision: 1.16 $ $Date: 2004/06/02 00:05:28 $ > > */ > > public class MathException extends Exception implements Serializable { > > > > /** Serializable version identifier */ > > static final long serialVersionUID = -8594613561393443827L; > > > > private Throwable cause = null; > > > > /** > > * Constructs a MathException > > */ > > public MathException() { > > super(); > > } > > > > /** > > * Create an exception with a given error message. > > * @param message message describing the problem > > */ > > public MathException(final String message) { > > super(message); > > } > > > > /** > > * Create an exception with a given error message and root cause. > > * @param message message describing the problem > > * @param throwable caught exception causing this problem > > */ > > public MathException(final String message, final Throwable throwable) { > > super(message, throwable); > > this.cause = throwable; > > } > > > > /** > > * Create an exception with a given root cause. > > * @param throwable caught exception causing this problem > > */ > > public MathException(final Throwable throwable) { > > super(); > > this.cause = throwable; > > } > > > > > > /* (non-Javadoc) > > * @see java.lang.Throwable#getCause() > > */ > > public Throwable getCause() { > > return cause; > > } > > > > /* (non-Javadoc) > > * @see java.lang.Throwable#printStackTrace() > > */ > > public void printStackTrace() { > > super.printStackTrace(); > > > > if(cause != null) > > cause.printStackTrace(); > > } > > > > /* (non-Javadoc) > > * @see java.lang.Throwable#printStackTrace(java.io.PrintStream) > > */ > > public void printStackTrace(PrintStream s) { > > super.printStackTrace(s); > > > > if(cause != null){ > > s.print("\n\nCaused By:\n\n"); > > cause.printStackTrace(s); > > } > > } > > > > /* (non-Javadoc) > > * @see java.lang.Throwable#printStackTrace(java.io.PrintWriter) > > */ > > public void printStackTrace(PrintWriter s) { > > super.printStackTrace(s); > > > > if(cause != null){ > > s.print("\n\nCaused By:\n\n"); > > cause.printStackTrace(s); > > } > > } > > > > } > > > > > > > > > > Henri Yandell wrote: > > > Seems to me that all you need is to add a getParentException method to > > > your Exception and Throwable to your constructors. Unsure just how much > > > you're inlining. > > > > > > Doing all the stuff Lang's exception stuff does seems unnecessary for > > > Math. Probably nothing new in this opinion :) > > > > > > Hen > > > > > > > > > On Thu, 8 Jul 2004, Phil Steitz wrote: > > > > > > > > >>I agree with both of you. The patch (though more testing has shown it > > >>is bugged) tries to bake all functionality of NestableException into > > >>MathException. It includes code from NestableDelegate and > > >>ExceptionUtils as well as NestableException. The simplest would be to > > >>copy and rename all of these classes, but I agree with Stephen's > > >>suggestion that it would be better to just borrow (er... I mean steal) > > >>the implementation code. The practical question is do we really need > > >>all of the functionality in the o.a.c.l.e.Nestable interface? I am > > >>travelling now, but when I get back this weekend if there are no > > >>objections I will commit a fixed version with more and better test cases > > >>and we can decide what, if anything, we can drop. > > >> > > >>Phil > > >> > > >> -----Original Message----- > > >> From: J.Pietschmann [mailto:[EMAIL PROTECTED] > > >> Sent: Thu 7/8/2004 3:19 AM > > >> To: Jakarta Commons Users List > > >> Cc: > > >> Subject: Re: [math] Eliminating [lang] dependency > > >> > > >> > > >> > > >> Mark R. Diggory wrote: > > >> > The only other alternative I can think of that may make things easier if > > >> > anything changes in the future would be to just copy NestableException > > >> > into the math package hierarchy under something like > > >> > o.a.c.m.exception.NestableException and extend it from there. > > >> > > >> Given that Java 1.4 Exceptions are nestable and already have > > >> most of the features of j.c.l.NestableException, I'd say that > > >> getting rid of NestableException is a good idea even at the cost > > >> of a significant but temporary code duplication. > > >> > > >> J.Pietschmann > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > > >> For additional commands, e-mail: [EMAIL PROTECTED] > > >> > > >> > > >> > > >> > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > > Mark Diggory > > Software Developer > > Harvard MIT Data Center > > http://www.hmdc.harvard.edu > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
