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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
