commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject Re: [collections] Transformer exception handling
Date Sat, 15 Jun 2002 17:36:40 GMT
From: "Peter Ko├ček" <>
> (A) Tunneling the #transform method with a wrapping runtime exception
> To help people doing that, we can give them an abstract implementation of
> Transformer which calls a method named #basicTransform from method
> #transform. Users of the abstract implementation have to overwrite
> #basicTransform. The #transform method of the abstract implementation is
> final and provides for a mechanism to wrap every checked exception into
> runtime exception.

I would rename basicTransform, maybe to handleTransform or doTransform -
slightly more obvious name to me. This technique has the advantage of
converting the exception to a runtime exception relatively transparantly,
which is more convenient in general. However, really its just doing a try
catch throw wrapped, which could be done by th application anyway.
> (B) Creating a new interface ExceptionalTransformer, which explicitly
> declares the wrapping exception, TransformerWrapperException.
>     public Object transform(Object o) throws TransformerWrapperException;
> As a consequence, the "normal" interface Transformer has to become a
> of ExceptionalTransformer so that people can easily switch from the
> #collect method to a special #collectWithException method if necessary.
>     public interface Transformer extends ExceptionalTransformer
> The introduction of ExceptionalTransformer into the existing API can be
> in a compatible way.

This is quite clever, and I think the transformer side would work. However,
it involves doubling the number of API methods for handling the use of
Transformer. This is quite an impact. Also, the exception thrown would need
to be Exception, which is really just a get around for it not being

> I have tried out both solutions. But my main interest here was to ask the
> question whether there are other people with the same problem. If my
> is the only one with that problem, I will implement solution (A) and no
> notice. However, if there are a lot of people who would like to be able to
> switch from a normal Transformer to an exceptional Transformer in the most
> seamless manner, it could be a good decision to introduce solution (B).

Over time I have come to dislike checked exceptions. This is an example of
why. I now use unchecked exceptions when I can. So, to confuse you, both
solutions appeal and neither solution appeals. I thus remain skeptical about
changing commons for transformation exceptions.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message