Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 75449 invoked from network); 16 Apr 2004 12:33:20 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 16 Apr 2004 12:33:20 -0000 Received: (qmail 16531 invoked by uid 500); 16 Apr 2004 12:33:16 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 16323 invoked by uid 500); 16 Apr 2004 12:33:14 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 16298 invoked from network); 16 Apr 2004 12:33:13 -0000 Received: from unknown (HELO mail.cbim.it) (212.131.130.82) by daedalus.apache.org with SMTP; 16 Apr 2004 12:33:13 -0000 Received: from cuprouter.cbim.it (cuprouter.cbim.it [192.168.4.10]) by mail.cbim.it (8.11.6/8.11.0) with ESMTP id i3GD32C10780 for ; Fri, 16 Apr 2004 15:03:02 +0200 Received: from cbim.it (caterina.cbim.it [192.168.4.42]) by cuprouter.cbim.it (8.9.3/8.9.3) with ESMTP id OAA07028 for ; Fri, 16 Apr 2004 14:34:35 +0200 Message-ID: <407FD287.7030402@cbim.it> Date: Fri, 16 Apr 2004 14:33:11 +0200 From: Ugo Cei Organization: C.B.I.M. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: [VOTE] Make ProcessingException extend CascadingRuntimeException References: <407F7DDB.2030905@apache.org> <407F8A17.2090208@cbim.it> <407F995B.3010209@cbim.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Nicola Ken Barozzi wrote: > Ugo Cei wrote: >> For 2.2 (which we have agreed will require JDK 1.4 IIRC, so we can >> count on exception chaining) I will propose to define a >> Cocoon-specific hierarchy of exceptions, whose root is >> java.lang.RuntimeException. And 3rd party exception classes like >> SAXException will have to be wrapped inside Cocoon-specific runtime >> exceptions. > Gaaak! Why so? I just don't get it, you don't like wrapping but are > going to do it nevertheless? I'm going to wrap only if I'm forced to or it adds value, i.e. information. Not just because I am forced by a "throws" clause in a method signature. If there's no "throws", I get to decide whether to wrap or not. >> How about this? >> >> } catch (ProcessingException e) { >> getLogger().debug("Rethrowing exception", e); >> throw new SAXException(e); >> } >> >> This is not only useless, it's plain wrong. > > First of all, why are you logging? Useless. Me? This is not code I wrote, it's in our CVS. I'm not into pshychic reading, but it seems to me quite evident that whoever wrote that code was feeling somewhat helpless or even guilty: "I don't know what to do with this ProcessingException that I'm *forced* to catch by the compiler, so I'm going to log it to share the burden of my guilt". But the author should not blame himself of feel guilty. He should blame the fact that ProcessingException is checked. Do you know what this is? This is a _code_ _smell_ and I want to remove it. Obviously, you appreciate checked exceptions more than I do, and there's nothing wrong with that. You are in Gosling's camp, and probably the majority of programmers is with you. I'm not going to change your mind and make you switch over to Eckel's camp in the space of a maling list thread. But let's be pragmatic. We have an *evident* code smell (I hope you at least agree with me on this point) and want to remove it. My pragmatic approach is: make ProcessingException extend CascadingRuntimeException, find all the lines of code that match this template: catch (ProcessingException e) { getLogger().*(*); throw new *Exception(*, e); } and simply remove them. *POOF* away goes the smell. If you don't agree, then what is your proposal? Ugo