At 8:44 am -0500 19/3/02, Vadim Gritsenko wrote:
>> From: Jeremy Quinn [mailto:[EMAIL PROTECTED]]
>>
>> At 7:59 am -0500 19/3/02, Vadim Gritsenko wrote:
>> >> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]]
>> >>
>> >> From: "Jeremy Quinn" <[EMAIL PROTECTED]>
>> >>
>> >> > Dear All,
>> >> >
>> >> > I am totally mystified as to how you are supposed to
>> >> > handle errors in
>> >> > webapps built using Cocoon.
>>
>> >> If you have a better solution, please commit it, we are all
>waiting.
>> >
>> >This reminds me of TODO item (in the todo.xml):
>> >----
>> > <action context="code">
>> > Check how to handle the mixing of output streams when an error
>inside
>> > a pipeline occurs. When the pipeline has something written to the
>> > output stream and then an error occurs the result is the first
>> >written
>> > part with the appended exception.
>> > One solution could be a configurable intermediate output stream.
>> > </action>
>> >----
>> >
>> >Jeremy, that's what you want, isn't it?
>>
>> I am not sure ..... ;)
>
>This means: Hold stream till end-of-processing. This allows: reset
>response completely, and output clean error page, without parts of XML
>previously processed.
Yes it makes sense now ..... this is something that could be useful as an
option for very specific pipelines.
>
>> If an internal pipeline makes an error, and has it's own
>error-handler, I
>> would hope that error could be inline,
>
>Then the pipeline which called this internal one will never know that
>exception happened: it will get either result, or partial result and
>error (IIRC).
This is what (I think) I want, subsequent XSLT will check the response from
the internal pipeline and act accordingly, this is how my pipelines detect
Validation errors from the Schematron validator, and decide not to write
the source when an error occurs, so this makes complete sense to me.
>> not tacked on at the end of all
>> processing, though I am obviously not understanding what is going on
>well
>> enough right now.
>
>Try also increasing buffer of the serializer, then environment will be
>able to reset the partial result and output clean error page. From the
>Environment:
>
>---------
> /**
> * Reset the response if possible. This allows error handlers to
>have
> * a higher chance to produce clean output if the pipeline that
>raised
> * the error has already output some data.
> *
> * @return true if the response was successfully reset
> */
> boolean tryResetResponse();
>---------
Sorry Vadim, you have lost me again .....
Thanks for your feedback
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<mailto:[EMAIL PROTECTED]> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pager:[EMAIL PROTECTED]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
