commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <benerit...@googlemail.com>
Subject Re: [BeanUtils2] Some proposals for an exception name
Date Mon, 18 Jun 2012 19:34:14 GMT
Hi,

I've started to implement BeanReflectionException and I want to take
the approach Simone suggested with the ErrorMessage from Digester. Now
I have a problem: If I want to pass the throwable cause as well, that
parameter has to be before the varargs argument. This would result in
the following constructor signature:

public BeanReflectionException( String messagePattern, Throwable
cause, Object... arguments )
or
public BeanReflectionException( Throwable cause, String
messagePattern, Object... arguments )

I don't like either, because the super constructor declares throwable
to be the last parameter. Now I could implement a builder for
BeanReflectionException that allows to construct
BeanReflectionExcetion in a fluent manner:

throw BeanReflectionException.withMessagePattern( "pattern"
).withArguments( "arguments" ).withCause( cause ).create();

But this seems to be a bit over-engineered for an exceptions that will
most probably never be constructed in user code. So I think I'll go
with public BeanReflectionException( Throwable cause, String
messagePattern, Object... arguments )

What do you think?

Benedikt

2012/6/18 Simone Tripodi <simonetripodi@apache.org>:
> Sounds even better!
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
> On Mon, Jun 18, 2012 at 12:33 PM, James Carman
> <jcarman@carmanconsulting.com> wrote:
>> BeanReflectionException?
>>
>> Sent from tablet device.  Please excuse typos and brevity.
>> On Jun 18, 2012 4:30 AM, "Simone Tripodi" <simonetripodi@apache.org> wrote:
>>
>>> Guten morgen, Bene,
>>>
>>> > My personal favorite is ReflectionException. I don't think, that we
>>> > should prefix classes wie BeanUtils*, because this information is
>>> > contained in the fully qualified class name.
>>>
>>> +1 I wouldn't happy at all to add a BeanUtilsException,
>>> ReflectionException sounds the good candidate for me as well, with
>>> following potential hierarchy:
>>>
>>> ReflectionException
>>>  - PropertyNotFoundException
>>>  - ReaderMethodNotFoundException
>>>  - WriterMethodNotFoundException
>>>  - ...
>>>
>>> > The problem is, that
>>> > there is already a ReflectionException in javax [2]. So I guess we can
>>> > not use that name?
>>>
>>> I don't see where the issue could be, since full qualified names would
>>> be different:
>>>
>>> javax.management.ReflectionException !=
>>> org.apache.commons.beanutils2.ReflectionException
>>>
>>> there are no chances for a naming conflict.
>>>
>>> A suggestion:
>>>
>>> we are often using the String.format() method to format Exception
>>> messages - which is very good, IMHO - and since we are introducing a
>>> new Exception we can take advantage for reducing its use, centralizing
>>> the message format in the new exception itself, have a look at the
>>> Digester's ErrorMessage <http://s.apache.org/wiR>
>>>
>>> Alles gute und dankeshön,
>>> -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