commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Sanders" <ssand...@nextance.com>
Subject RE: [BeanUtils] Added Initial DynaBeans Support
Date Wed, 09 Jan 2002 21:20:58 GMT
I'm with b)

Scott

> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org] 
> Sent: Wednesday, January 09, 2002 1:16 PM
> To: Jakarta Commons Developers List
> Subject: Re: [BeanUtils] Added Initial DynaBeans Support
> 
> 
> 
> 
> 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>
> 
> 

--
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