Hi James, I think that analyzed cases by Benedikt still sound good, adding 'semantic' for each defined exception. I wouldn't expect users will be forced on try/catch blocks... anyway I suggest to start with Bene's codebase and refine it while working on BU2, depending of how the component evolves - we started from a situation where users were really forced on try/catch multiple checked exceptions and going to an API which allows users code in a cleaner way, since there are a lot of rooms for improvement let's the component evolve... WDYT?
thanks and best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Jun 20, 2012 at 12:49 PM, James Carman <jcar...@carmanconsulting.com> wrote: > I thought folks agreed to stick with one generic exception and only add > when it makes sense. Does this really make sense? That is a rather large > hierarchy. Are people really going to put catch blocks for any of those > specific exceptions? > > Sent from tablet device. Please excuse typos and brevity. > On Jun 20, 2012 2:58 AM, "Benedikt Ritter" <benerit...@googlemail.com> > wrote: > >> 2012/6/19 Simone Tripodi <simonetrip...@apache.org>: >> >> The point is with "Property %s not found in %s type" you're embedding >> the >> >> relevant data in the message text and a client would have to parse the >> text >> >> if a special handling is required. >> > >> > I would never force poor users parsing the exception message to >> > understand what is wrong - I would add getters to the exception to >> > retrieve both propertyName/targetClass of PropertyNotFoundException, >> > in the same way users are used to invoke the getCause() method. >> > Apologize for not having been explicit on this! >> > >> >> I'm working on this issue and I've created a hierachy like this: >> >> BeanReflectionException >> - PropertyNotFoundException (Wraps IntrospectionException) >> - PropertyNotReadableException (Wraps NoSuchMethodExcpetion) >> - PropertyNotWirteableException (Wraps NoSuchMethodException) >> - PropertyNotAccessibleException (Wraps IllegalAccessException) >> - MethodInvocationException (Wraps InvocationTargetException) >> - - PropertySetterInvocationException (Wraps InvocationTargetException) >> - - PropertyGetterInvocationExcpetion (Wraps InvocationTargetExcpetion) >> >> Right now I've a lot of code duplication, that I have to get rid of >> before I create the new patch. >> Beside that there is one other issue I'm not exactly sure how to deal >> with. In my first patch attached to >> https://issues.apache.org/jira/browse/SANDBOX-423 I've catched all >> exceptions in DefaultBeanAcessor.get(String propertyName). That >> results in a lot of try catch code in that class. Now I'm thinking >> that it might be a better approach to handle exception where they >> first appeared. For example we could catch the NoSuchMethodException >> in DefaultBeanProperties. That would scatter the exception handling >> everywhere around in the code, but it would reduce the overhead in >> DefaultBeanAcessor. What do you think? >> >> Benedikt >> >> > -Simo >> > >> > http://people.apache.org/~simonetripodi/ >> > http://simonetripodi.livejournal.com/ >> > http://twitter.com/simonetripodi >> > http://www.99soft.org/ >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > For additional commands, e-mail: dev-h...@commons.apache.org >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
