commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter_Kos...@t-online.de (Peter Ko├ček)
Subject [collections] Transformer exception handling
Date Sat, 15 Jun 2002 10:57:36 GMT
Hello.

Are there any afficionados of Transformer exception handling around?

A lot of java programmers have to take care about declared exceptions. E.g.,
if I call the message #getAddress to an object of a class named Customer,
the address may be loaded on demand from the underlying database system,
which results in the following method signature:

    public Address getAddress() throws DatabaseLoadException { // ... }

Thus, the following code cannot compile:

    CollectionUtils.collect(
        aCustomerCollection,
        new Transformer() { public Object transform(Object o) {
            return ((Customer) o).getAddress();}};

We can't use CollectionUtils#collect to transform a customer list into an
address list, because the Transformer interface method #transform
doesn'tallow for checked exceptions.

Do we have a problem here? Couldn't we say: "SIGH - boy, you should stop
that stupid usage of lazy initialization. Let some session bean initialize
the address of the customer and then rewrite the #getAddress method again
without throwing any exceptions. Within the ideal world of bean application
development, no one throws any database exceptions."? I do
believe we still have a problem here. (Without a doubt, the problem is
almost bigger than the question whether to write aficionado with one or two
f's.) If I am committed to use the code of other people, I also have to
commit to handle with the *problems* of other people. Other people may throw
checked exceptions to make it clear to me that I have to care about
one of *their* problems. Same as it ever was.

If we have no strategies to solve Transfomer exception handling, it will
lower the acceptance of the Transformer interface ernestly.
1. Developers could argue: "I don't understand why Transformer is sometimes
usable and sometimes not. So, I won't use Transformer because it is not
universal enough. When I think about a collection of things to be
transformed, I don't want to change my coding style depending on the
question of checked exceptions." You have to, buddy.
2. Developers who could use Transformer can shrink from doing that because
they had to live in steadily fear of the day when a third party introduces a
new checked exception, which will end up in a horrorful supporting scenario
if there are many widespread uses of Transformer.

So I think Transformer exception handling is a concern to be addressed. Open
discussion is needed. I suggest to solve the problem in the way of an
add-on. People who can't use Transformer are invited to use the add-on. One
big question for me is how to tie together the "normal" Transformer with the
add-on exceptional Transformer.

There is an alternative with two solutions, both of them using a wrapper
exception which transports the original exception to the caller of the
CollectionUtils#collect method. The caller of the #collect method (or maybe
a second API like #collectWithException) has to unwrap the original
exception and can then proceed as usually.

(A) Tunneling the #transform method with a wrapping runtime exception
To help people doing that, we can give them an abstract implementation of a
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 the
runtime exception.

(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 subtype
of ExceptionalTransformer so that people can easily switch from the "normal"
#collect method to a special #collectWithException method if necessary.
    public interface Transformer extends ExceptionalTransformer
The introduction of ExceptionalTransformer into the existing API can be done
in a compatible way.

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 project
is the only one with that problem, I will implement solution (A) and no one
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).

How do you think about that?

Greetings,
Peter




--
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