cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [VOTE] Make ProcessingException extend CascadingRuntimeException
Date Fri, 16 Apr 2004 14:37:47 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. 

It should usually never add information. If it has more information than 
the base, it can usually handle it completely.

> Not just because I am forced by a "throws" clause in a 
> method signature.

You are forced by a contract, just as you are forced by other types.

> If there's no "throws", I get to decide whether to wrap or not.

Or you don't decide at all.
>>> 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 know, man. What I say is that the fact that it gets logged has 
*nothing* to do with unchecked exceptions. It seems that for you one has 
unchecked exceptions or the thing that you have written above. Stop 
polluting the discussion with these things as they are not involved.

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

He should blame the fact that he does not have ProcessingException in 
*it's* throws cause even if he cannot cope with it.

> Do you know what this is? This is a _code_ _smell_ and I want to remove it.

I never remove code smell. If it works, don't touch it, even if it 
smells. If it doesn't work, fix it. Code beauty and lack of odor only 
creates nice empty boxes, and I know something about it unfortunately.

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

Yeah, great, let's just remove the code.

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

    catch (ProcessingException e) {

      //see if I *really* need to rethrow it

      throw new *Exception(*, e);
    }

or simply let it be rethrown if possible. I would prefer a lot to rather 
add ProcessingException to the throws cause of these components, as this 
is how it should have been done if the contract actually needs it.

PLUS

Get it right with 2.2 by defining the contract with the container, IE 
what the component.

Since you know that we have dozens of places in the code with this 
thing, do you care posting a dozen of them here?

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


Mime
View raw message