In general I agree with Bertrand that it's nicer to add a "throws Exception" to an Interface to tell the user that something can go wrong.
You will get to add a "throws Exception" to any method only over my dead body ;-).
And we shouldn't forget that some exceptions are treated differently, for example the ResourceNotFound exception (that's the reason for the ugly exception handling code in SourceUtil). This exception is treated by the sitemap engine differently from other exceptions and we shouldn't loose this feature.
Indeed. That's why I propose that ProcessingException extends CascadingRuntimeException, instead of CascadingException. This way, you won't be forced to catch it (and catch ResourceNotFoundException) if you don't need to and be tempted to wrap it or swallow it.
The sitemap engine can continue catching it as it does now.
The litmus test should be the following: can you recover from a ResourceNotFoundException, in the general case? IMHO, no. Your best course of action is to tell the user.
If I'm not mistaken, reparenting ProcessingException would require zero changes in other components, it would be a totally backward-compatible change, but could allow us to remove lots of useless code. So I'm proposing to do this for 2.1.5.
Removing or changing the "throws" clause of public interfaces would be an incompatible change, so we can discuss it for 2.2 or later.
Ugo
