cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: [VOTE] Make ProcessingException extend CascadingRuntimeException
Date Fri, 16 Apr 2004 13:28:26 GMT

Ugo Cei wrote:

> 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.

which sounds like more arbitrary decissions and thus 'surprise-code'

I will be left to wonder why you suddenly wrap it now?

and the answer will be only in the fact that somebody further up your 
call-stack has a special handling case for this?

>>> 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.

hm, slightly exagerated? IMHO there is an equal drive to do this logging 
coming from the fact that the class was LogEnabled :-)

> 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.

Ugo, I don't think this is about camps, at least not in my head, I 
really found the Eckel's view and enteresting read and a pure 
revelation: I find it to broaden my view on the issue (in general)

As I tried to mention before: general views can help us see, but we have 
to look into our project-details ourselves.

> 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.

hehe, this makes me think about a humor-radio-program we had years ago 
on belgian radio, people were asked to invent a perfect 'perfume'

turns out that was shaped like: [two plugs you put into your own nose]

removing the smell is admirable, making it smell good is better

> If you don't agree, then what is your proposal?

sigh, making it smell good is hard work, that's what I hinted at when 
saying there is no easy answer...

I'm not currently not convinced there could be anything else then 
careful consideration on each point in the code, sorry if this is bad news.

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                          

View raw message