I'm with b) Scott
> -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > 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 <[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:commons-dev-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
