Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <407FF5E6.70308@leverageweb.com>
Date: Fri, 16 Apr 2004 11:04:06 -0400
From: Geoff Howard <cocoon@leverageweb.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.6) Gecko/20040113
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [VOTE] Make ProcessingException extend CascadingRuntimeException
References: <A22ADD8E-8F28-11D8-AAD9-000A95DC4186@apache.org>
 <407FD9E1.4050904@leverageweb.com> <407FE74A.1050302@cbim.it>
In-Reply-To: <407FE74A.1050302@cbim.it>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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