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

Hi Berin:

Guess what - I'm going to jump into this thread with a bunch of 
disageements!
(and I'm sure you will agree with the disagreements)

:-)


Berin Loritsch wrote:

>>From: Noel J. Bergman [mailto:[email protected]]
>>
>>Leo wrote:
>>    
>>
>>>True, but here we're really going into whether RuntimeExceptions
>>>should be tested for and caught.
>>>      
>>>
>>Personally, I have an extremely dim view of the lazy use of 
>>RuntimeException instead of properly declaring exceptions in the 
>>interface.   Debugging them in client code is a PITA as it is, 
>>and in this case because we are dealing with a dynamic assembly 
>>model, the an end user deployment may be calling a component that 
>>the developer has never seen.
>>    
>>
>
>
>Its a PITA any way you look at it.
>

This is only a PITA if the container does not handle the scenario. 
 First issue is that the container has to assume that everything will go 
wrong - and as such, any container has to be very attentive and very 
robust.  If a container API meets this criteria it can provide valuable 
feedback to the developer.

 1. bootstrap
     - is the container valid
     - are available types and profiles declared to the container well 
formed

 2. assembly request management
      - is the component declared (meta etc.)
      - is the meta declaration valid
      - are all depedencies (service, context, lifecycle extensions)
        resolvable

3. deployment request management
    - lifestyle
        - is it declaring a valid lifestyle
    - lifecycle
        - are directives relating to configuration, parameters,
          context, initilization, startup, shutdown and disposal
          achievable
        - does the component pass through deployment

4. decommissioning management

   - depedencies
      - decomissioning management for dependecies
      - disposal

If there is a failure during any of the above, the container should
be handling the graceful decommissioning - RuntimeException or
otherwise.

>  
>
>>In this case, the Container is passing in a narrow type with 
>>the expectation
>>that the class will downcast it.  Personally, I *would* recommend the
>>try-catch coding pattern, and doing it immediately in contextualize.
>>    
>>
>
>Yep, or at the *very least* casting it immediately in contextualize so
>that the container can catch that problem.
>  
>

Runtime resolution here is not different to runtime resolution in the 
initialization stage, startup or execution stages.  The container is 
responsible for trapping errors and handlined component decommmissioning 
(and resolution of decommissioned compoent decommissioning).

>  
>
>>Berin Loritsch wrote:
>>    
>>
>>>A *Container* needs to be able to recover from ALL exceptions
>>>thrown by components.  This is a real practical requirement.  If
>>>a poorly written optional component introduces a 
>>>NullPointerException or a ClassCastException, and the container 
>>>does not catch it and recover from it then the whole application 
>>>will fail.
>>>      
>>>
>>I agree that container (and all platform code) should be 
>>robust.  But here's a rub.  There is no guarantee that the 
>>Component won't take the Context, squirrel it away, and cast the 
>>thing later when it needs it.  And when THAT happens, who sees the 
>>ClastCastException?  Quite likely some other component, whom is not 
>>expecting those kinds of internal errors to leak out.
>>    
>>

Disagree - the container can handle these conditions - if its not in 
contextualize state then it will be in the initialization stage or the 
starup stage,  In each case, the container has to take responsibility 
for tracking runtime errors and handling the decommission responsibilities.

Cheers, Steve.

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:[email protected]
http://www.osm.net