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 Simons <le...@apache.org> on 2002/06/12 17:58:24 UTC
[summary] declared vs runtime vs no exceptions
one of the points of debate left after Leo Sutic's summary of the A5 CM
discussion is that of exception throwing.
> The ComponentManager interface:
>
> interface ComponentManager {
> /**
> * Issues:
> *
> * - Should it throw Exceptions on failed lookup or return null?
> */
> public Object lookup (String role);
This is a broader topic: many of the classes related to the lifecycle
interface methods (ComponentManager, Context, ...) throw (specialized,
declared, non-runtime exceptions).
Summary
=======
Stefano raised this issue, stating that unnecessary exception throwing
slows an application down; which Leo Sutic refuted
(http://marc.theaimsgroup.com/?l=avalon-dev&m=102369972301164&w=2).
Furthermore, the burden imposed on component developers was mentioned as
they'll have to write try/catch/finally statements, where it would be
more convenient to have RuntimeExceptions as those do not have to be
caught.
In cases where finally{} is not necessary, this is not true, as the
component developer can usually opt to not to catch the exception and
have it cascade back to the container (ie, ComponentManager.lookup()
called within compose() does not have to be surround by try{} in that
case as compose() throws the same exception as lookup).
The question here (#1): is it desirable to impose a burden like this
(which is not *that* big) on component developers?
- If the answer is no, then a RuntimeException is an alternative.
It has also been argued that exceptions should only be used in
"exceptional" circumstances, and that a lookup failing is not
exceptional, but can sometimes be expected.
The question here (#2): where is it an "exception" to have a method
fail, and where is it really "normal" behaviour that should be
communicated in a different way?
- In cases where we really deal with "normal" behaviour, the only other
viable communication option is to return null, resulting in either a
test against null, or a NullPointerException.
my answers:
#1 - generally, yes. The alternative is to either have them not know
(RuntimeException) which will possibly lead to memory leaks, or to have
them deal with a possible return of "null"
#2 - I can't think of places in avalon framework where an exception is
thrown while there is no true exception; it would still be good to
evaluate this.
IOW, no changes neccessary.
thought:
It could be nice to formalize the way we handle exceptions (like the XML
Axis project) a little more.
regards,
- Leo Simons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [summary] declared vs runtime vs no exceptions
Posted by Peter Donald <pe...@apache.org>.
At 06:31 PM 6/12/2002 +0200, you wrote:
> > >IOW, no changes neccessary.
> > >
>
>
>If this means that we keep it as it is now (not as it is in my summary),
>then +1.
+1
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [summary] declared vs runtime vs no exceptions
Posted by Leo Simons <le...@apache.org>.
> >thought:
> >It could be nice to formalize the way we handle exceptions (like the XML
> >Axis project) a little more.
> >
>
> Can you expand on this ?
> (for those of us too lazy to surf)
> :-)
Apache Axis (over at XML) has a really big developer's guide:
http://cvs.apache.org/viewcvs.cgi/~checkout~/xml-axis/java/docs/developers-guide.html
among which is some stuff about exceptions:
http://cvs.apache.org/viewcvs.cgi/~checkout~/
xml-axis/java/docs/developers-guide.html#Exception Handling
(note: wrapped link)
Some of this is applicable to all software (and we could copy or
reference), some only to Axis.
Basically, we could have a "recommended avalon programming practices"
page, which describes the way IoC/SoC and the exception mechanism work
together.
stuff like:
Everything a container (is this a good idea for composer?) passes to a
child component should only throw exceptions which the container
(composer?) knows about, so the child component has the option to send
the exception back to the container. This enables rapid prototyping of
components.
In code, it looks like this:
interface SomeComponentInterface
{
public someMethod( SomeSpecificObjectInterface ) throws
SomeComponentException;
}
interface SomeSpecificObjectInterface
{
public Something someMethod() throws SomeMethodException;
// or just SomecomponentException
}
interface Something {}
class SomeComponentException extends Exception {}
class SomeMethodException extends SomeComponentException {}
class SomeComponent implements SomeComponentInterface
{
Something m_something;
public someMethod( SomeSpecificObjectInterface obj )
throws SomeComponentException
{
m_something = obj.someMethod();
// no try/catch neccessary
}
}
Examples of this setup within avalon framework can be found in the
Composable/ComponentManager/ComponentException and the
Contextualizable/Context/ContextException interfaces and classes.
---
There's lots of stuff like that, usage scenario's like JavaBeans, which
we don't enforce, don't mention, don't document, but still use. It's not
required to work with avalon, but it can be quite useful.
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [summary] declared vs runtime vs no exceptions
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> >IOW, no changes neccessary.
> >
If this means that we keep it as it is now (not as it is in my summary),
then +1.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [summary] declared vs runtime vs no exceptions
Posted by Stephen McConnell <mc...@osm.net>.
Leo Simons wrote:
>one of the points of debate left after Leo Sutic's summary of the A5 CM
>discussion is that of exception throwing.
>
>
>
>>The ComponentManager interface:
>>
>>interface ComponentManager {
>> /**
>> * Issues:
>> *
>> * - Should it throw Exceptions on failed lookup or return null?
>> */
>> public Object lookup (String role);
>>
>>
>
>This is a broader topic: many of the classes related to the lifecycle
>interface methods (ComponentManager, Context, ...) throw (specialized,
>declared, non-runtime exceptions).
>
>Summary
>=======
>Stefano raised this issue, stating that unnecessary exception throwing
>slows an application down; which Leo Sutic refuted
>(http://marc.theaimsgroup.com/?l=avalon-dev&m=102369972301164&w=2).
>
>Furthermore, the burden imposed on component developers was mentioned as
>they'll have to write try/catch/finally statements, where it would be
>more convenient to have RuntimeExceptions as those do not have to be
>caught.
>In cases where finally{} is not necessary, this is not true, as the
>component developer can usually opt to not to catch the exception and
>have it cascade back to the container (ie, ComponentManager.lookup()
>called within compose() does not have to be surround by try{} in that
>case as compose() throws the same exception as lookup).
>
>The question here (#1): is it desirable to impose a burden like this
>(which is not *that* big) on component developers?
>
Its desirable.
>- If the answer is no, then a RuntimeException is an alternative.
>
>It has also been argued that exceptions should only be used in
>"exceptional" circumstances, and that a lookup failing is not
>exceptional, but can sometimes be expected.
>
>The question here (#2): where is it an "exception" to have a method
>fail, and where is it really "normal" behaviour that should be
>communicated in a different way?
>
I'm not aware of any areas of issue.
I consider modification of the exceptiuon usage as unnecesary revision
to the framework interfaces and would be opposed to the idea based on
information provided todate.
>
>- In cases where we really deal with "normal" behaviour, the only other
>viable communication option is to return null, resulting in either a
>test against null, or a NullPointerException.
>
>my answers:
>#1 - generally, yes. The alternative is to either have them not know
>(RuntimeException) which will possibly lead to memory leaks, or to have
>them deal with a possible return of "null"
>
>#2 - I can't think of places in avalon framework where an exception is
>thrown while there is no true exception; it would still be good to
>evaluate this.
>
>IOW, no changes neccessary.
>
+1
>
>thought:
>It could be nice to formalize the way we handle exceptions (like the XML
>Axis project) a little more.
>
Can you expand on this ?
(for those of us too lazy to surf)
:-)
--
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>