avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen McConnell" <mcconn...@osm.net>
Subject RE: ExcaliburComponentManager
Date Fri, 07 Dec 2001 22:33:04 GMT


Reply in-line down below somewhere.

Berin Loritsch wrote:
> Stephen McConnell wrote:
> > Leo:
> > 
> > The error occurred when creating a class that extended
> > ExcaliburComponentManager - the derived class contained 
> > implementations of the initalize or contextualize methods 
> > corresponding to the Initializable and Contextualizable 
> > interfaces.  The compiler complained because my new
> > class was declaring the exceptions (I was including the 
> > respective throws clause).  So, to be absolute correct - the 
> > compilation error was on my class - not 
> > ExcaliburComponentManager.  However, the compilation error
> > arrived because ExcaliburComponentManager implementation 
> > doesn't declare the respective exceptions.
> > 
> > What is interesting here is that ExcaliburComponentManager 
> > implements the Initializable and Composable interfaces 
> > without declaring the required exceptions and yet this 
> > compiles ok (which I confess I don't understand).
> This has to do with inheritance.  Java allows you to hide exceptions for
> inherited methods, but you cannot add them.  This is because the 
> super class implementation declares the set of exceptions that it 
> will allow.  You can get more specific--but you cannot go outside 
> that set.  Once you eliminate the exception in the inheritance 
> hierarchy, you have a super class that has a smaller set than the 
> base class.  Anything that extends this super class
> now must repect *it's* declared set of exceptions.
> The comments in the following heirarchy of classes will help you 
> understand. 

> The question is, is there a *reason* you want to throw an 
> exception from the subclasses of ExcaliburComponentManager or 
> are you declaring it to be semantically correct?

(a) the initial situation was that the declaration was made to be 
    semantically correct
(b) this raised the compilation problem because ECM changes the
    definition of what is semantically correct as you and Leo have
    pointed out
(c) which led us to ignore ECM in favour of DefaultComponentMnager
    because we need to be able to throw an exception 

[snip OO tutorial (with the comment that I've been dealing with 
interface 98% of the time and this one caught me by surprise) :-)]

Conclusion ... should ECM throw the classic lifecycle exceptions or 
not?  As it stands its easier to work with but its not useful for 
extension.  Its not a big deal because we (OSM) can do what we want 
with DefaultComponentManager (as distinct from the LifecycleHelper
issue that I still need to battle with Pete about and the 
PhoenixServlet issue which is basically a lack of documentation 
problem - both of which I'll get to sometime soon).

Cheers, Steve.

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message