You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Jeff Turner <je...@socialchange.net.au> on 2002/03/29 06:44:47 UTC
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
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 :)
--Jeff
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Removing dep on CascadingException in collections
Posted by Jeff Turner <je...@socialchange.net.au>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Removing dep on CascadingException in collections
Posted by Peter Donald <pe...@apache.org>.
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.
--
Cheers,
Pete
---------------------------------------
Be nice to your friends. If it weren't
for them, you'd be a complete stranger.
---------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Removing dep on CascadingException in collections
Posted by Berin Loritsch <bl...@apache.org>.
> -----Original Message-----
> From: Jeff Turner [mailto:jeff@socialchange.net.au]
>
> On Fri, Mar 29, 2002 at 08:54:00AM -0500, Berin Loritsch wrote:
> > > -----Original Message-----
> > > From: Jeff Turner [mailto:jeff@socialchange.net.au]
> ...
> > > 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.
>
> Good. Btw, I see the same situation in the Event code.. :)
The Event code is still scratchpad--even though I want to
finalize it soon. We can fix it.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Removing dep on CascadingException in collections
Posted by Jeff Turner <je...@socialchange.net.au>.
On Fri, Mar 29, 2002 at 08:54:00AM -0500, Berin Loritsch wrote:
> > -----Original Message-----
> > From: Jeff Turner [mailto:jeff@socialchange.net.au]
...
> > 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.
Good. Btw, I see the same situation in the Event code.. :)
...
> > because I can't think why anyone would want to typecast a
> > RuntimeException, which are not even meant to be caught, let
...
> 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.
Ah ok. I meant, as opposed to regular Exceptions which must be
explicitly caught or let through.
--Jeff
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Removing dep on CascadingException in collections
Posted by Berin Loritsch <bl...@apache.org>.
> -----Original Message-----
> From: Jeff Turner [mailto:jeff@socialchange.net.au]
> Sent: Friday, March 29, 2002 12:45 AM
> To: avalon-dev@jakarta.apache.org
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>