You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Sutic <le...@inspireinfrastructure.com> on 2002/12/11 20:32:19 UTC
Exceptions (was: RE: [Avalon4:PROPOSAL] Context Consensus)
> From: Noel J. Bergman [mailto:noel@devtech.com]
>
> > I prefer for the component to [do] the cast and explode if
> it fails.
> > The responsibility is on the container to catch and log the
> exception.
>
> The contract throws ContextException. There is nothing in
> the API contract that says that a container must
> intelligently handle ClassCastException, or what it might
> mean semantically.
True, but here we're really going into whether RuntimeExceptions
should be tested for and caught. In the end I guess it just matters
how much defensive programming you want to put in. Your example
is too much for me to accept as a coding guideline, but if you
want to write code that way...
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Exceptions (was: RE: [Avalon4:PROPOSAL] Context Consensus)
Posted by Stephen McConnell <mc...@apache.org>.
Stephen McConnell wrote:
> 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).
And what I meant to say was:
"(and resolution of dependent component decommissioning)."
---------
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Exceptions (was: RE: [Avalon4:PROPOSAL] Context Consensus)
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> 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
> scenario 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
> implements the class
> without necessarily instantiating it.
>
> The same logic applies to a new or revised context interface.
It is still a fragile contract.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Exceptions (was: RE: [Avalon4:PROPOSAL] Context Consensus)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Well, I don't entirely agree, but we're drifting way off-topic, and into
areas that are far from being coded.
> One step at a time ....
Yup.
Now if I could only figure out what the next one is ... ;-)
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Exceptions (was: RE: [Avalon4:PROPOSAL] Context Consensus)
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>>I (as spokesperson for Merlin) can gaurantee you that the object
>>provided to you will be castable to you requested interface and
>>that it will be supplid with the requested keys fully populated
>>and that each key value will be castable to the requested interface.
>>
>>
>
>Well, I'm not a big fan of such dependency upon external configuration
>files, but that's a moot point. You can do that in the context (small c) of
>current Avalon containers and conditions.
>
>However, we've already seen one developer wanting to expand Avalon to use
>JINI, for example. Any component can ask for any other component at any
>time in a dynamically populated environment. How do you expect to make JINI
>compliant, or any other dynamically populated environment? I understand
>that you don't expect to be there before AV5.
>
>
It's not an issue - this is simply a component implementation - and if
that implentation does something worg, then the container has to act to
rectify the situation (whatever the particular status of the component).
The container does not care about JNDI - it only cares about specific
states of the components it is managing + the components that are
depedent on that component. If that target component fuctions within
the guidlines of the A4.1 contract then fine - otherwise its a case of
handling damage control (which is a semi-complex exercise).
On the subject of the seperation of a single source from meta-info ..
yes I agree that its not perfect, but I also think this is oniy a
question of build tools. Today, I'm not convinced that the meta API is
totally what we want and as such I'm not about to ivest time into those
tools - it much more production to get the meta rights - then make the
code/meta synchronization an automatic process.
One step at a time ....
:-)
Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Exceptions (was: RE: [Avalon4:PROPOSAL] Context Consensus)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I (as spokesperson for Merlin) can gaurantee you that the object
> provided to you will be castable to you requested interface and
> that it will be supplid with the requested keys fully populated
> and that each key value will be castable to the requested interface.
Well, I'm not a big fan of such dependency upon external configuration
files, but that's a moot point. You can do that in the context (small c) of
current Avalon containers and conditions.
However, we've already seen one developer wanting to expand Avalon to use
JINI, for example. Any component can ask for any other component at any
time in a dynamically populated environment. How do you expect to make JINI
compliant, or any other dynamically populated environment? I understand
that you don't expect to be there before AV5.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Exceptions (was: RE: [Avalon4:PROPOSAL] Context Consensus)
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>>I'm not disagreeing.
>>
>>
>
>All I'm saying is that there probably ought to be a best practice to avoid
>the problem so long as this flawed interface survives.
>
>
>
>>The same logic applies to a new or revised context interface.
>>
>>
>
>The AV5 approach shouldn't really have the problem to the same extent
>because the Context object passed shouldn't require casting. But this is
>actually a reason for why I had proposed Context.get(Key, Class), which
>would tell the container exactly what kind of interface I was expecting to
>receive.
>
This is not adding anything that we can't already do i A4.1 + container.
If you decalre th following meta:
<type>
<context type="x.y.z.BlockContext">
<entry key="urn:avalon:work" type="java.io.File"/>
<context>
</type>
I (as spokesperson for Merlin) can gaurantee you that the object
provided to you will be castable to you requested interface and that it
will be supplid with the requested keys fully populated and that each
key value will be castable to the requested interface.
Imagine that we have an avalon framework meta contract - and imagine
that every single avalon container implements that meta contract. That
means you don't need to worry, becuase the container will assure that
what you get is what you want (irrespective of what actions you take at
runtime). If you do additional defensive coding, its only because your
intending to run your component in a non-compliant framework.
That's my view of the direction we should be heading towards with
respect to the Avalon V Containment API.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Exceptions (was: RE: [Avalon4:PROPOSAL] Context Consensus)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I'm not disagreeing.
All I'm saying is that there probably ought to be a best practice to avoid
the problem so long as this flawed interface survives.
> The same logic applies to a new or revised context interface.
The AV5 approach shouldn't really have the problem to the same extent
because the Context object passed shouldn't require casting. But this is
actually a reason for why I had proposed Context.get(Key, Class), which
would tell the container exactly what kind of interface I was expecting to
receive.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Exceptions (was: RE: [Avalon4:PROPOSAL] Context Consensus)
Posted by Stephen McConnell <mc...@apache.org>.
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:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Exceptions (was: RE: [Avalon4:PROPOSAL] Context Consensus)
Posted by "Noel J. Bergman" <no...@devtech.com>.
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.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Exceptions (was: RE: [Avalon4:PROPOSAL] Context Consensus)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Nicola,
> Tell me that I should expect runtime or nullpointer exceptions, and my
> alarm bells will start ringing so hard it could heafen half the world ;-)
When I find code explicitly throwing runtime exceptions, it is healthier for
the author to be nowhere near me. But that is usually a reaction to having
just debugged a problem where someone threw a runtime exception, didn't
document that it might, and I didn't catch it deep enough.
Runtime exceptions are a necessary evil (think of a typical null pointer or
index out of bounds), but evil. They should be used with great discretion.
Runtime exceptions are undocumented far too often by authors, and even if
you think to have internal "firewalls" to catch them in reasonable places,
you can overlook something.
I wish that Sun had named the class "UndeclaredException", which provides
the correct semantic spin. Doug Lea had an interesting proposal for
addressing them: http://gee.cs.oswego.edu/dl/html/javaCodingStd.html.
One of my other peeves is directed at code that throws exceptions without
putting sufficient information in the exception to diagnose the correction.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Exceptions (was: RE: [Avalon4:PROPOSAL] Context Consensus)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Noel J. Bergman wrote:
> Not necessarily. Consider this poorly written example:
>
>
> Exactly. Thanks for providing the example (and a not unlikely one). :-)
>
> If nothing more, best practice should acknowledge the fragility of the
> contract.
Just one note.
I have been dealing with varying success with exception handling in many
projects.
Tell me that I should expect runtime or nullpointer exceptions, and my
alarm bells will start ringing so hard it could heafen half the world ;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Exceptions (was: RE: [Avalon4:PROPOSAL] Context Consensus)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Not necessarily. Consider this poorly written example:
Exactly. Thanks for providing the example (and a not unlikely one). :-)
If nothing more, best practice should acknowledge the fragility of the
contract.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Exceptions (was: RE: [Avalon4:PROPOSAL] Context Consensus)
Posted by Berin Loritsch <bl...@citi-us.com>.
> >>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.
Not necessarily. Consider this poorly written example:
public interface DoSomethingService {
void doSomething();
}
public class MyBadComponent implements Contextualizable, DoSomethingService
private Context m_context;
/**
* The context is not immediately used or cast--making container
* detection of a bad component during initialization impossible.
*/
public void contextualize( Context context ) {
m_context = context;
}
/**
* The cast is done at runtime, when another component or client uses
* the service. The client code will be the unhappy recipient of the
* ClassCastException.
*/
public void doSomething() {
( (BlockContext) m_context ).requestShutdown();
}
}
The only way to handle this scenario is to have a Proxy surround calls to
the runtime interface and intercept the RuntimeExceptions that should never
be thrown--i.e.. NullPointerException, Class**Exception (NotFound, Cast,
etc.),
and let through RuntimeExceptions that should be thrown--i.e..
IllegalArgumentException.
It also demonstrates that an ambiguous service can do something you don't
really want ;).
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Exceptions (was: RE: [Avalon4:PROPOSAL] Context Consensus)
Posted by Stephen McConnell <mc...@apache.org>.
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:noel@devtech.com]
>>
>>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:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Exceptions (was: RE: [Avalon4:PROPOSAL] Context Consensus)
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Noel J. Bergman [mailto:noel@devtech.com]
>
> 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.
> 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.
> 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.
And then the component fails regarding its contracts... Anyway
I consider the practice a fragile contract at best.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Exceptions (was: RE: [Avalon4:PROPOSAL] Context Consensus)
Posted by "Noel J. Bergman" <no...@devtech.com>.
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.
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.
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.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Exceptions (was: RE: [Avalon4:PROPOSAL] Context Consensus)
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
>
> > From: Noel J. Bergman [mailto:noel@devtech.com]
> >
> > > I prefer for the component to [do] the cast and explode if
> > it fails.
> > > The responsibility is on the container to catch and log the
> > exception.
> >
> > The contract throws ContextException. There is nothing in
> > the API contract that says that a container must
> > intelligently handle ClassCastException, or what it might
> > mean semantically.
>
> True, but here we're really going into whether RuntimeExceptions
> should be tested for and caught. In the end I guess it just matters
> how much defensive programming you want to put in. Your example
> is too much for me to accept as a coding guideline, but if you
> want to write code that way...
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.
It is a QoS (Quality of Service) issue.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>