commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <benerit...@googlemail.com>
Subject [BeanUtils2] Thoughts about the API
Date Thu, 14 Jun 2012 17:30:32 GMT
Hi,

while working on BU2, I was thinking about the API and what may be improved.

Exceptions:
Right now a lot of API methods just populate the checked reflection
exceptions like InvocationTargetException from the native java
reflection API. This dooms Java 6 users to write code like:

try {
   Bean clone = on( original ).cloneBean();
} catch (IllegalAccessException iae) {
   // what to do here?
} catch (InstantiationException ie) {
   // and here?
} catch (IntrospectionException ie2) {
   // and here?
} catch (InvocationTargetException ite) {
   // and here?
} catch (NoSuchMethodException nsme) {
   // and here?
}

The missing javaDoc for some exceptions shows, that I myself was
unsure in what cases some exceptions will occure.
To overcome this, users may implement something like:

try {
   Bean clone on( original ).cloneBean();
} catch (Exception e) {
   // now nothing can go wrong, right?
}

The problem is, that this will swallow useful RuntimeExeptions (for
example like IllegalArgumentException when passing null to a primtive
property).
I see several solutions:
1. update BU2 to Java 7. We could make use of
ReflectiveOperationException [1]. Beside that users can use the new
multi catch blocks.
2. Wrap checked exceptions into RuntimeExceptions. The question is,
what a user can do to recover from one of those exceptions. Only if
there is something the user can do, it would make sense to throw a
checked exception.
3. leave everything as is

All tree solution have pros and cons. I think that having a method
like cloneBean() throw 5 checked exceptions feels rather clumsy. So I
prefer the second option. What do you think?

Processing of Annotations:
Do we have access of annotations on our agenda? I can imagine something like:

on ( bean.getClass() ).getAnnotation( "annotationName" ).fromMethod(
"methodName" ).getValue( "valueName" );

The exact API would have to be discussed. But in general, I think this
fits nicely into BU2.

Changing of MappedProperty(Getter|Setter)Accessor:
A while ago we decided to shorten method names as much as possible.
For example we changed BeanAccessor.getProperty(String propertyName)
to BeanAccessor.get(String propertyName). However, we did not change
the methods on MappedProperty(Getter|Setter)Accessor and
ArgumentsAccessor, all three classes define "withXXX" as methods.

How do you feel about changing
MappedProperty(Getter|Setter)Accessor.withKey(String key)
to
MappedProperty(Getter|Setter)Accessor.for(String key)
so that ArgumentsAccessor.withArguments( Argument... Arguments )
can be changed to
ArgumentsAccessor.with( Argument... Arguments )

This would result in a fluent call like:
on( bean ).getMapped( "mappedProperty" ).for( "theKey" );
and
on( bean ).setMapped( "mappedProperty" ).for( "theKey" ).with( value );
and
on (bean ).invoke( "methodName" ).with( value1, value2, value3);

Regards,
Benedikt

[1] http://docs.oracle.com/javase/7/docs/api/java/lang/ReflectiveOperationException.html

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


Mime
View raw message