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
> 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
>
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 brevit
2012/6/19 Simone Tripodi :
>> 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
> understa
> 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 gett
Hi Simo,
Simone Tripodi wrote:
> 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 messag
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, h
Hi Simo,
Simone Tripodi wrote:
[snip]
>>> 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 fo
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
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
wrote:
> BeanReflectionException?
>
> Sent from tablet device. Please excuse typos and
BeanReflectionException?
Sent from tablet device. Please excuse typos and brevity.
On Jun 18, 2012 4:30 AM, "Simone Tripodi" wrote:
> Guten morgen, Bene,
>
> > My personal favorite is ReflectionException. I don't think, that we
> > should prefix classes wie BeanUtils*, because this information
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
Hi,
following up on the thread where we discussed about the current state
of the API [1], I want to discuss how to name the generic
RuntimeException we talked about. Here are some proposals:
1. BeanUtilsException
2. BeanUtilsReflectionException
3. ReflectionException
4. ReflectiveAcessException
13 matches
Mail list logo
