commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Gaspar" <paulo.gas...@krankikom.de>
Subject RE: [BeanUtils] Added Initial DynaBeans Support
Date Thu, 10 Jan 2002 00:38:05 GMT
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:craigmcc@apache.org]
> 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 <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