commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ola Berg <>
Subject Re: [collection] Transformer exception handling
Date Sat, 15 Jun 2002 19:37:07 GMT
Steven Colebourne wrote:

>I don\'t agree with the comment  \"some reflection almost always is there\".  I
>believe there are plenty of transformations that don\'t need reflection.

Yes, you are right. As I can see, you use transformations for many different purposes. I use
them mainly for type-conversions, which means that I instantiate objects dynamically in my
transformations, hence heavy use of reflection.

(I use a different Call interface for encapsulating method-calls when I need to do programatical
things dynamically).

>This technique has the advantage of
>converting the exception to a runtime exception relatively transparantly,
>which is more convenient in general. 

Well, IMHO \"convenient\", just as loosely typed languages are convenient (at first). Declared
Exceptions has the advantage that it makes you consider the exceptional case. You need to.
=less error prone code.

Generally, I see a need for both lax and strict programming styles, for different purposes.
When it comes to exceptions, I\'m all for the principle that states \"RuntimeException for
those things you could foresee (like NullPointerException), and Exception for those things
that can happen no matter how cautious you are (like IOException)\".

And speaking with architectural lenses on my goggles: 

Isn\'t the problem here that there is more to generic Transformations than any of the proposed
interfaces can handle? Compare with event listeners in Swing: they are in a sense encapsulated
actions/transformations/messengers (or should invoke a such). But they don\'t allow exceptions
to be passed. You are thus force to handle them elsewhere. 

With that in mind, I am all for keeping Transformations without exceptions, as long as we/you/me/other
can present a decent and supported pattern (with supporting classes) that solves that generic
problem (how to handle exceptions elsewhere).

I have done experiments in putting an ExceptionHandler that swallows the exceptions, but passes
them to a different (plugable) handler architecture as messages, so that the caller doesn\'t
have to deal with it. I am not pleased with my attempts, but something needs to be done, if
one wants to be able to encapsulate operations into generic interfaces, lest we let the interfaces
throw the generic Throwable. 


0733 - 99 99 17

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

View raw message