cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ugo Cei <u....@cbim.it>
Subject Re: [VOTE] Make ProcessingException extend CascadingRuntimeException
Date Fri, 16 Apr 2004 14:47:35 GMT
Joerg Heinicke 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.

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.

	Ugo

[1] :

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


Mime
View raw message