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:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
