If the end-result of this is users seeing more stacktraces, or plain 404 or 500 errors, I go -1.
Users should see *shorter* and more meaningful stacktraces.
If the end result is developers can still "catch" errors in the sitemap and display custom "oops" pages instead (as currently) then I go to +0.
There is no plan to remove "catch" clauses from the sitemap processor, so the usual <map:handle-errors> should still work as usual.
If, however, this means backwards incompatibility or behavior change with existing components (external too, not only in our cvs) then I go back to -1 no matter what.
Removing a checked exception from the "throws" clause of a method declaration is a backward-compatible change.
However, if we later on decide that this was not a good idea after all, readding a checked exception is backward-incompatible. This would only affect people who wrote code, calling this method without a try-catch block, in the interval between the two changes. I think that this is quite improbable and easily caught.
Hope this clears your doubts.
Ugo
