commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <>
Subject Re: [BeanUtils2] Some proposals for an exception name
Date Tue, 19 Jun 2012 14:16:28 GMT
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 message format in the new exception itself, have a look at the
>>>>> Digester's ErrorMessage <>
>> A better approach is IMHO the Contexted(Runtime)Exception of the
>> oac.lang3.exception package. Instead of writing a prose for the message
>> text, you can use a short informative statement and add all relevant
>> additional information in a structured way with the possibility to be
>> evaluated properly by a client. You may even enrich the information at
>> higher levels by catching the exception, adding the info and rethrow it
>> again.
> I like the approach, thanks Jörg!!! I think we can reuse some ideas to
> improve the BU2 Exceptions design.
> Contexted(Runtime)Exception is good for multi purposes applications
> and dynamic contexts, BU2 has already known contexts, i.e. in a
> potential PropertyNotFoundException the context is identified by the
> missing property in the target class, so BeanReflectionException could
> become kind of Contexted(Runtime)Exception and
> PropertyNotFoundException could just be
> PropertyNotFoundException( String propertyName, Class<?> target,
> Throwable cause )
> {
>     // impl here
> }

I think you missed the point. This "context" has nothing to do with the one 
of BU2. If PropertyNotFoundException where a ContextedRuntimeException, you 
would have implemented something like:

PropertyNotFoundException( String propertyName, Class<?> target, Throwable 
cause )
  super("Property not found", cause);
  setContextValue("Property name", propertyName);
  setContextValue("Bean type", target);

and if this exception is thrown somewhere deep in a subroutine you could add 
more context with e.g.:

try {
 // call somthing that throws this PropertyNotFoundException
} catch (ContextedRuntimeException e) {
 throw e.addContextValue("File", filename);

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. And you may have to nest the exceptions 
deeper as necessary to add additional information.

The message is:

========== %< ========
AnotherException: Error processing file %s
   at ...
caused by: PropertyNotFoundException: Property %s not found in %s type
   at ...
========== %< ========


========== %< ========
PropertyNotFoundException: Property not found
  Property Name: %s
  Bean type: %s
  File: %s
   at ...
========== %< ========

The general implementation decision is the consequent usage of exceptions 
with context or to use them not at all.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message