avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@osm.net>
Subject Re: [summary] declared vs runtime vs no exceptions
Date Wed, 12 Jun 2002 16:07:53 GMT

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).
>Stefano raised this issue, stating that unnecessary exception throwing
>slows an application down; which Leo Sutic refuted
>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
>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.


>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

digital products for a global economy

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