Perhaps you could defer this decision of whether to return null vs throw
exception behavior to a 'policy' class.
Such an object could be provided by the user via an api. Users would be able
to provide their own implementations:
public class ExceptionHandlerPolicy {
public boolean shouldPropagate(Object context, Exception exception);
}
-----Original Message-----
From: robert burrell donkin
[mailto:[EMAIL PROTECTED]]
Sent: Monday, December 16, 2002 11:29 AM
To: Jakarta Commons Developers
Subject: [lang] MethodUtils exception handling
the rest of org.apache.commons.lang.reflect wraps all exceptions in
nestable ReflectionExceptions. so this is how i originally converted them.
on the other hand, when i took a look around, client code is actually
reasonably likely to want to handle the different kinds of exception
differently. for example, digester now traps InvocationTargetException's
and throws SAXException's based on the original exception thrown by the
method. most clients will want to know when a method can't be found.
so i'm now coming to the conclusion that maybe we need to throw individual
exceptions.
invokeMethod has to throw an exception to indicate that a method can't be
found.
but should getMethod return a null or should it throw an exception if it
doesn't find a method? (the version in beanutils tended to return nulls
and i tend to agree.)
comments anyone?
- robert
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
