[lang] MethodUtils exception handling

[robert burrell donkin <ro...@blueyonder.co.uk>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [lang] MethodUtils exception handling

[Stephen Colebourne <sc...@btopenworld.com>]

Actually I consider removing the burden of some of these exceptions to be a
benefit. Maybe a selective policy:

InvocationTargetException - returned from method invokes
NoSuchMethodException - returned from method searches
all others are wrapped.

In particular I wanted to wrap some of the more unusual errors and
exceptions and try to provide clearer error messages. Hence the method in
ReflectionUtils.

Stephen

From: "robert burrell donkin" <ro...@blueyonder.co.uk>
> 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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>