On 9 Jan 2002, Bryan Field-Elliot wrote:
> Date: 09 Jan 2002 14:01:31 -0700
> From: Bryan Field-Elliot <[EMAIL PROTECTED]>
> Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]>
> To: Jakarta Commons Developers List <[EMAIL PROTECTED]>
> Subject: Re: [BeanUtils] Added Initial DynaBeans Support
>
> On Wed, 2002-01-09 at 13:02, Craig R. McClanahan wrote:
>
> Although I've added some simple unit test cases (based on the
> existing
> ones for standard JavaBeans), it would be really useful if some more
> folks
> tried out DynaBeans in the real world, and provided some feedback
> before
> we lock down the APIs for them.
>
>
> The DynaBean set() methods do not throw any exceptions. This makes it
> hard (in fact, impossible) for me to layer any exception semantics on
> top of the base implementation. For example, in my own implementation
> (which "extends BasicDynaBean", but could just as easily be a class
> which "implements DynaBean"), I can't enforce a read-only semantic by
> way of throwing an exception. Right now, I'm just returning without any
> action taken. Kind of silly.
>
Good points. The same issues actually apply to get() methods too.
The alternatives seem to be:
(a) Status quo -- this mimics your typical JavaBean with simple
getter and setter methods for local properties, but doesn't work
well for wrapping RMI objects or EJBs, and essentially requires
swallowing any exceptions.
(b) Require that exceptions be rethrown as a RuntimeException. This
has the advantage of not requiring try/catch blocks around every
use of the getter and setter calls, but the disadvantage in that
there is no declaration that significant exceptions are possible.
(Note that in JDK 1.4, RuntimeException has constructors that
take a "root cause" exception, along with a message).
(c) Add "throws InvocationTargetException" to all the get() and
set() method calls. This is consistent with what you have to
deal with if you use reflection to call methods directly, and
how we would use it is pretty faithful to the semantics in the
InvocationTargetException javadocs. However, this would require
*all* uses of DynaBean getters and setters to be encapsulated in
try/catch blocks.
(d) Add "throws Exception" to all the get() and set() methods. This
makes DynaBean implementations slightly easier (they can just
pass on application exceptions without having to pay attention),
and is otherwise pretty similar to (c).
My personal leaning is for (b) right now, with (c) being in second place.
What does everyone else think?
> Thanks,
>
> Bryan
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
