On Fri, Mar 29, 2002 at 07:43:05PM +1100, Peter Donald wrote: > On Fri, 29 Mar 2002 16:44, Jeff Turner wrote: > > In my case, I have: > > > > public class CascadingRuntimeException // in framework > > > > public class BufferOverflowException > > extends CascadingRuntimeException // in Excalibur's collections package > > > > > > I'd like to remove that dependence, since it's the only thing tying > > collections to framework. The public interface will be identical, but > > typecasts will break. > > go for it. ExceptionUtil has recently been enhanced to use reflection to get > at "cause" of exception if the exception does not implement > CascadingThrowable. This was to ease integration with jdk1.4. > > However it is not turned on by default (I thought it may be a CPU hit) - > maybe we should turn it on by default? Given that printing out the exception > is likely to be more costly CPU-wise anyway.
The collections code currently doesn't set the nested exception anyway, so even if the introspection was used, there'd be no visible change. In general.. printing a stack trace should be a pretty unusual activity, so perhaps the performance hit isn't too important. --Jeff (breaking off concurrent.. and then the Simpsons started.. will be done soon) > -- > Cheers, > > Pete > > --------------------------------------- > Be nice to your friends. If it weren't > for them, you'd be a complete stranger. > --------------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
