commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: [BeanUtils2] Some proposals for an exception name
Date Wed, 20 Jun 2012 11:07:53 GMT
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
<jcarman@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" <beneritter@googlemail.com>
> wrote:
>
>> 2012/6/19 Simone Tripodi <simonetripodi@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-unsubscribe@commons.apache.org
>> > For additional commands, e-mail: dev-help@commons.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message