Has I said, I am with (b) too. I already tried the alternatives and it was too painful. I mean, I use DynaBeans EVERYWHERE!
The RuntimeExceptions are made for things like this. A similar case in the JDK is the java.util.Map: when an implementation is not readable or does not implement an "optional" method it throws a RuntimeException. Besides this... > (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). Avalon as a nice set of exception classes, which include (some names might be wrong): - CascadingThrowable (an interface) - CascadingException - CascadingRuntimeException - CascadingError - ExceptionTool All the CascadingXXX classes implement the CascadingThrowable interface which just has a Throwable getCause(); method. You can use this classes directly or by extending them, of course. (I bet the JDK 1.4 copied this one from Avalon! (o;= ) The ExceptionTool takes care of getting "causes", printing or just getting information of multiple cascading levels, etc. It is a very small but very useful package. I extended the ExceptionTool class to make it return other types of causes using introspection to find if an exception object implements some method like this one: public java.lang.Throwable getRootCause() or public java.lang.Throwable getCause() after, of course first checking if its just an implementation o the CascadingThrowable interface. I should contribute this one back! =:o/ Have fun, Paulo Gaspar http://www.krankikom.de http://www.ruhronline.de > -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 09, 2002 10:16 PM > > > > 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
