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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
