Geoff Howard wrote:
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.
No, that was my point. Developers should see shorter more meaningful stacktraces. Users should never see a stack trace in my opinion. I know this is a semantic difference between "users" of the cocoon framework, and users of the applications they build. I thought what you are proposing is not in conflict with this, but I didn't have time to figure that out myself, hence my comment.
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.
There you go. Sorry you had to spell it out explicitly.
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.
I think this is probably OK risk. I'm on +0 now.
Geoff
