cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <coc...@leverageweb.com>
Subject Re: [VOTE] Make ProcessingException extend CascadingRuntimeException
Date Fri, 16 Apr 2004 15:04:06 GMT
Ugo Cei wrote:

> 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

Mime
View raw message