Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 45407 invoked by uid 500); 29 Apr 2003 16:34:26 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 45322 invoked from network); 29 Apr 2003 16:34:23 -0000 Received: from onramp.i95.net (205.177.132.17) by daedalus.apache.org with SMTP; 29 Apr 2003 16:34:23 -0000 Received: from apache.org ([66.208.12.130]) by onramp.i95.net (8.12.9/8.12.9) with ESMTP id h3TGYQwT016506 for ; Tue, 29 Apr 2003 12:34:26 -0400 Message-ID: <3EAEA990.10006@apache.org> Date: Tue, 29 Apr 2003 12:34:24 -0400 From: Berin Loritsch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: Allow redirects inside error handling References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Bj�rn L�tkemeier wrote: > Hi, > > >>Perhaps Cocoon should detect potential infinite loops as a feature. >> > > > that would really be a very great feature solving the problem, any idea how > to implement it ;-) > > But as I said: In my opinion it is not the task of the underlying system > (Java, Cocoon or whatever) to prevent or detect infinite loops. It is and > remains to be a mistake of the developer. But if he nonetheless likes to > redirect in an error handler for whatever reason, he should be able to. At > any other point of the sitemap he has this possibility, too. This is where we disagree whole-heartedly. Let me ask you, what do you do with exception handling? You can't use code that can generate new exceptions unless you nest a new try/catch block inside that. Eventually you have to do one of two things: give up and die or handle the exception as gracefully as possible. Think of error handlers in the same way. The Java language, and many other languages restrict what you can do in an exception/error handler. Since you are so fond of using the language as an example of how to do things, here is an example of where the language restricts what you can do. There needs to be some restrictions in your error handlers, and I will restate that you should not allow anything that can generate an error in an error handler, unless your user explicitly handles that error as well. -- "You know the world is going crazy when the best rapper is a white guy, the best golfer is a black guy, The Swiss hold the America's Cup, France is accusing the US of arrogance, and Germany doesn't want to go to war. And the 3 most powerful men in America are named 'Bush', 'Dick', and 'Colon' (sic)". -----Chris Rock