cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject Re: [VOTE] Make ProcessingException extend CascadingRuntimeException
Date Fri, 16 Apr 2004 19:30:29 GMT
On 16.04.2004 16:47, Ugo Cei wrote:

>>> The compiler forces you to catch them.
>>
>> Of course, but only exactly once at the end. How are the exceptions made
>> available to handle-errors at the moment? I guess somewhere in the tree
>> processor. So where is the problem letting it catch the exception? I 
>> still don't
>> see the need for the re-parenting.
> 
> No. Assuming there are several layers, currently the compiler forces you 
> to catch the exception at every layer or declare it in the throws clause 
> (which might be impossible if you're implementing an interface).
> 
> On the contrary, if PE extends RuntimeCascadingException, you have the 
> freedom to catch it only in the outermost layer, that would probably be 
> the sitemap processor. Or you can catch it wherever you like.
> 
> The conventional wisdom is that it's better to have the compiler remind 
> you that you have to catch most exceptions, because that's part of the 
> contract. My opinion, instead, is that checked exceptions are a very bad 
> way of enforcing contracts between callers and callees.

This is where I don't follow you.

> The conventional wisdom is also that strong type checking helps in 
> enforcing contracts. Judging from the recent flourishing of untpyed or 
> weakly-typed languages like Python, Ruby, Groovy or Javascript [1], I'd 
> be inclined to doubt that wisdom too.

Same here. Do you remember this one: 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107901388024464&w=4 ?? 
If I change the implementation to a Set the statement will fail. I need 
many more tests than with strong-typing. But the same way I do not want 
to care about request and form handling - I use an abstracting framework 
for it, and care only about business logic - I do not want to care about 
testing correct types. The only tests I want to write are about business 
logic.

What I hate in Java are untyped collections, that force me to cast when 
retrieving an object out of them, and long vs. Long (was it called 
auto-boxing?). Both will be fixed in Java 1.5 IIRC.

Joerg

> [1] :
> 
> function myflow() {
>   var obj = cocoon.getComponent(id);
>   obj.someMethodThrowingCheckedException();
>   // What? No cast? No try-catch? Where's the compiler??? ;-)
> }
> 
> 

Mime
View raw message