commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Peter Ko├ček)
Subject Re: [collections] Transformer exception handling
Date Sun, 16 Jun 2002 10:30:38 GMT
> 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
> changing commons for transformation exceptions.

Until now, I have accepted checked exceptions as a must to make reliable
software. On the other hand, they are a showstopper to build elegant
framework-like utilities or to make rapid prototypes. If my application
prototype can work fine on a single PC in the first phase of my project, why
should I spend hours to handle RemoteException? If I know that my
ToStringTransformer will work without problems, why should I catch

My idea was to allow for non-exceptional and exceptional transformations to
live in harmony. We could make a subclass of CollectionUtils named
ExceptionalCollectionUtils which implements public methods like
#collectWithException and can use the protected method #doCollect from its
superclass. So we separate the exceptional stuff from the main library
without losing contact to it.

The basic transforming method within CollectionUtils is

    public static Collection collect(Iterator,  final Transformer,  final
Collection) { // ... }

If we split it into two methods

    protected static final Collection doCollect(Iterator,  final
ExceptionalTransformer, final Collection)
        throws TransformerWrapperException


    public static Collection collect(Iterator inputIterator,
                                                    final Transformer
                                                    final Collection
outputCollection) {
        try {
            return doCollect(inputIterator,  transformer,  outputCollection)
        } catch (TransformerWrapperException e) {
            // Don't catch any checked exception here because we *know*
Transformer doesn't throw one
            // #doCollect can also be used from other callers with
ExceptionalTransformer        }

then we can use #doCollect within a subclass of CollectionUtils within a new

    public static Collection collectWithException (Iterator inputIterator,
                                                    final Transformer
                                                    final Collection
        throws TransformerWrapperException {
        return super.doCollect(inputIterator,  transformer,

If ExceptionalCollectionUtils wasn't a subclass of CollectionUtils but a
class within the same package, we could change the name of the method from
#collectWithException to #collect.

Thus, we could separate the complex exception handling transformation into a
certain class without throwing the universal Exception from a public method.
Only the mechanism to implement ExceptionalTransformer has to throw and
catch a universal exception.

public abstract class AbstractExceptionalTransformer implements
ExceptionalTransformer {
  public final Object transform(Object o) throws TransformerWrapperException
    try {
      return this.doTransform(o);
    } catch (Exception e) {
      if (e instanceof RuntimeException) {
        // don't wrap runtime exceptions again
        throw (RuntimeException) e;
      } else {
        throw new TransformerWrapperException(e);
    * method to handle any transforming code who can throw a checked
    * This method is called by the #transform method of this class, which
    * wrap the exception into a TransformerWrapperException
  protected abstract Object doTransform(Object o) throws Exception;

After all, I can understand that you don't want to change the basic design
of the transforming mechanism. My argument for a change was to help people
who have the need to use code with checked exceptions. The other way round,
people who want to use Transformer very often will be incited to minimize
the usage of checked exceptions within their code.


P.S.: Perhaps we should have a new Java keyword called 'throws same'.
A method which declares 'throws same' tells us that it throws everything
from the underlying methods. The caller of a method which 'throws same' has
to handle exactly the same exceptions than the underlying methods of the

For example, we then have

    #callerMethod throws MissionImpossibleOnMondaysException
        - calls -> #collect throws same
            - calls -> #transform throws same
                - calls -> #someWorkerMethod throws

But I don't know whether it is possible to create a compiler for that,
especially on Mondays. `:-)

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

View raw message