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. /O -------------------- [EMAIL PROTECTED] 0733 - 99 99 17 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
