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" <[EMAIL PROTECTED]> > 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]>
