Re: Exceptions (was: RE: [Avalon4:PROPOSAL] Context Consensus)

Stephen McConnell <[email protected]>
Newsgroups gmane.comp.jakarta.avalon.apps.devel,gmane.comp.jakarta.avalon.devel
Message-ID <[email protected]>

Noel J. Bergman wrote:

>Stephen,
>
>Yes, containers should be robust.  But imagine that a component is passed a
>context that is not of the correct type, and it doesn't cast it in
>contextualize.  It puts it away to use later.  As it turns out, that
>component rarely uses context.  It only needs the context to perform a
>particular operation, which it will perform upon request for some other,
>possibly third-party, component.  So this application is running fat, dumb
>and happy for some indefinite period of time until out of nowhere a
>ClassCastException ripples out of a component.
>
>Probably not the best situation.  Hence my suggestion to at least check the
>cast early.
>  
>

I'm not disagreeing.

In such a scenario, I would put in place a test case that did the 
casting - and avoid object activation whenever possible.  For example, I 
will typically use the methof hasService( key ) on the ServiceManger to 
validate that the key is available - but I will pass on the service 
manager to subsidiary components without actually getting the value of 
the key - that because in the assembly API service don't get activated 
until they are actually needed - that makes lookup an expensive 
operation on the first hit operation.  What would be better in that 
scanario would be a hasService( key, class ) method where class is 
parameter that is the target cast class and the implementation of the 
service manger can validate if the candidate object implememts the class 
without necessarily instantiating it.

The same logic applies to a new or revised context interface.

Cheers, Steve.

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:[email protected]
http://www.osm.net
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.