Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Sender: giacomo
Message-ID: <3A1EF40E.6F9F8BB4@apache.org>
Date: Sat, 25 Nov 2000 00:04:46 +0100
From: Giacomo Pati <giacomo@apache.org>
Organization: Apache Software Foundation
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [C2]Action proposal (long)
References: <3A119876.19728.8C44B4@localhost>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

maciejka@tiger.com.pl wrote:
> 
> On 14 Nov 2000, at 0:50, Giacomo Pati wrote:
> 
> >
> > --- maciejka@tiger.com.pl wrote:
> > > ...
> > > Why not to let actions throw exceptions and catch them in sitemap:
> >
> > It's already there! A <pipeline> can have a <handle-error> element
> > which you can fillup with <transform> and <serialize> to suit your
> > need. The thrown exception will be handled by an internal generator
> > which converts the Exception into a defined DTD (see
> > org.apache.cocoon.Notifier).
> >
> 
> My itention is to use exceptions to break execution of chained
> actions and communicate reason of the break to the sitemap.

To break the chain we could define a BreakChainException to signal it to
the sitemap. But you still need to set some values in the context to
make other components able to verify it (i.e a selector).

> <handle-error> purpose is to handle fatal situations, I suppose, and
> can't be used to handle exceptional, but not fatal situations
> ocurring during action execution.

Correct.

> Other problem with <handle-error> I see:
> If administrator can't choose generator for given error than
> error handling is up to transformation author, not up to site
> administrator? Is it constistent with Cocoon goal to keep contexts
> (management and style) from overlaping?

Well, there is no need to select another generator for an error
situation. An error is an error, point. It's descibed in a DTD and thats
it. You are able to style the error if you want to present it to the
client.

Giacomo
> 
> Maciek Kaminski
> maciejka@tiger.com.pl