Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 24151 invoked from network); 11 Aug 2002 19:42:42 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 11 Aug 2002 19:42:42 -0000 Received: (qmail 10909 invoked by uid 97); 11 Aug 2002 19:43:06 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 10748 invoked by uid 97); 11 Aug 2002 19:43:05 -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 10734 invoked by uid 98); 11 Aug 2002 19:43:05 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) X-Authentication-Warning: costinm.sfo.covalent.net: costin owned process doing -bs Date: Sun, 11 Aug 2002 12:38:49 -0700 (PDT) From: costinm@covalent.net X-X-Sender: costin@costinm.sfo.covalent.net To: Jakarta Commons Developers List cc: nicolaken@apache.org Subject: Re: DBCP/LANG In-Reply-To: <004201c2414e$f14ff980$2a8027d9@oemcomputer> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Sun, 11 Aug 2002, Stephen Colebourne wrote: > > I'm +1 for removing NestableException from lang, in favor of utulity > > methods. > > -1 > We don't all use JDK 1.4. NestableException is a highly useful way of > handling exceptions. The fact that everyone tends to write their own > suggests that there should be a common implementation. I know that not > everyone favours exception wrapping, but it is a recognised technique used > by many people in many places including the JDK. This will stay. I think you got it wrong. Everyone is designing exceptions based on their needs - and it is indeed a very common pattern to use a getCause() on the exception, and tools like the logger can use this pattern ( and introspection in pre-1.4, Throwable.getCause() in 1.4 ). That doesn't mean there is a need for a NestableException base class that projects should use ( i.e. TomcatException extends NestableException). There is need for common code to parse the stack trace and helper to manipluate the nested exceptions - but [lang] is completely useless for that, if a project doesn't extend NestableException, it won't get any help. In other words - I don't think tomcat ( for example ) will change the exceptions to extend NestableException, especially when the same benefits can be achieved using a tool that can manipulate arbitrary exception ( including ServletException, etc ). Of course, that doesn't mean I want it removed from lang - just that it raises red flags for me, as I said I don't like very much utils that require users to change their APIs ( and the exception hierarchy is part of the API). Since commons allows duplication - I'll just wait for a general-purpose exception helper that will do the same thing on arbitrary exceptions. Costin -- To unsubscribe, e-mail: For additional commands, e-mail: