[collections] Exception handling

[James Strachan <ja...@yahoo.co.uk>]

Hi Peter

I've CC'd the commons-dev list

----- Original Message -----
From: "Peter Koßek" <Pe...@t-online.de>
> Hello.
>
> We're using the 'Jakarta Commons-Collections' library in our team, and it
> was very nice experience for me to use the Predicate Interface with the
> #select and #find API of class CollectonUtils.
>
> But now, one of our programmers begins to work with the Transformer
> interface and the #collect API, and he has some problems. I want to ask
you
> for a hint.
>
> He wants to write a Transformer to translate an object from some database
> interface into a user domain object.
> The method to translate the object can throw some checked exception, let's
> call it 'DatabaseConnectionException'.
>
> The programmer doesn't want to clear the exception. Normally, he would
write
> 'throws DatabaseConnectionException' into the declaration of his method.
But
> unfortunately, the #transform method of the Transformer interface doesn't
> allow that.
>
> What can we do now? We can argue about a lot of alternatives, so let's do
> it.
>
> 1. Tunneling the #transform method with an unchecked runtime exception
>     We can define a so-called TransformationException, which contains the
> original exception.
>     A caller of CollectionUtils#collect catches that exception, unwraps it
> and throws the original error again.
>     Pro: It works.
>     Con: The programmer of the #transform method has to learn so much
stuff
> about that TransformationException
>         he never wanted to know about anytime before. We told him "using
the
> Transformer can be so elegant",
>         and now he has to make some additional work he never could
imagine.
>
> 2. Putting any result of the transformation into the result collection
("the
> taming of the throw")
>     The Transformer only knows to transform, and if the result of the
> transformation is an exception, well,
>     we will add the exception to the result collection. If someone
> complains, we could also put null into the result.
>     Pro: It works again (if we wouldn't transform a collection of
> exceptions),
>         and the #transform method programmer will quickly learn what to
do.
>             try { // transform s.th.
>             } catch (Exception e) {return e;}
>     Con: The caller of the #transform method has to learn so much stuff
> about that
>         transformation result collection he never wanted to be told about
> anytime before.
>         We told him "using the Transformer can be so elegant", and now he
> won't come with us for dinner any more.
>
> 3. Introducing a Transformation API which accepts checked exceptions
>     To use the Transformer universally, we have to accept that checked
> exceptions will fly from the transformation
>     through the collection up to the using method. So we have to introduce
> another Transformer method
>     and a new CollectionUtils method, which declare the following: 'throws
> Exception'.
>     Pro: The #transform method programmer doesn't need to learn about
dirty
> tricks.
>     Con: We have to wrap every #collect into a 'try ... catch'.
>
> 4. Application level programming vs. system level programming
>     Application programmers won't write code which causes transformations
to
> throw checked exceptions,
>     only system level programmer will do that. So, a normal application
> programmer can use the Transfomer
>     interface, and a system programmer won't do it.
>
> Which solution would you prefer?
>
> At the moment, I would tend to a mixture between 1. and 3. We can declare
> the #transform method with 'throws exception', but the
> CollectionUtils#collect can catch that error and wrap it with a special
> runtime error, so that the user of the #collect method can decide that he
> knows there won't be checked exceptions any more, so that he doesn't need
to
> write a 'try ... catch'.
>
> Greetings,
> Peter Koßek

You could write your own Transformer facade to handle specific exceptions in
a particular way, such as maybe retrying N times if a database deadlock
occurs or whatever. When you simply need to throw an Exception, probably
using some kind of TransformationRuntimeException that you can catch and
handle accordingly might be the easiest solution.

I'd always envisioned Predicate, Closure and Transformer to be fairly
lightweight operations that shouldn't fail; that they should perform their
own exception handling. I guess the only resort is to use RuntimeExceptions?
I'm not sure I like the idea of these 3 interfaces throwing checked
exceptions.

I wonder what others thoughts are on this?

James



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>