From: "Ola Berg" <[EMAIL PROTECTED]> > >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)\".
Accepted. (I do use checked exceptions). > 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. I'm interested - have you looked at Morphos yet?? Stephen -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
