Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 64774 invoked from network); 15 Jun 2002 20:39:18 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 15 Jun 2002 20:39:18 -0000 Received: (qmail 10558 invoked by uid 97); 15 Jun 2002 20:39:24 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 10543 invoked by uid 97); 15 Jun 2002 20:39:23 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 10531 invoked by uid 98); 15 Jun 2002 20:39:23 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Message-ID: <009901c214ad$21b06020$343929d9@oemcomputer> From: "Stephen Colebourne" To: "Jakarta Commons Developers List" , "Ola Berg" References: Subject: Re: [collection] Transformer exception handling Date: Sat, 15 Jun 2002 21:42:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N From: "Ola Berg" > >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: For additional commands, e-mail: