> -----Original Message----- > From: Jeff Turner [mailto:[EMAIL PROTECTED]] > Sent: Friday, March 29, 2002 12:45 AM > To: [EMAIL PROTECTED] > Subject: Removing dep on CascadingException in collections > > > Hi, > > A general question about compatibility. If we have two classes: > > public class Base { ... } > public class Derived extends Base { ... } > > I would like to make Derived no longer extend Base, but > otherwise maintain API compatibility by reimplementing Base's > public methods. Any code that typecasts Derived to Base will > break. I'm wondering, do we (or should we) guarantee this > sort of compatibility? > > In my case, I have: > > public class CascadingRuntimeException // in framework > > public class BufferOverflowException > extends CascadingRuntimeException // in Excalibur's > collections package
We can probably do it in this case. If people cast the Exception to anything, it was RuntimeException or BuferOverflowException. > 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. > > I this case, I think the advantage weighs out the cost, > because I can't think why anyone would want to typecast a > RuntimeException, which are not even meant to be caught, let > alone played with. But that's just me. So I'll go ahead with > the change, and roll back if anyone disagrees :) RuntimeExceptions are meant to be caught, because they can be gracefully recovered from. It is Errors that are not meant to be caught--you can't do anything to recover from it. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
