commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: [BeanUtils] Added Initial DynaBeans Support
Date Wed, 09 Jan 2002 21:15:42 GMT


On 9 Jan 2002, Bryan Field-Elliot wrote:

> Date: 09 Jan 2002 14:01:31 -0700
> From: Bryan Field-Elliot <bryan_lists@netmeme.org>
> Reply-To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> 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:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message