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??? ;-)
}



Reply via email to