cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <jer...@media.demon.co.uk>
Subject RE: error handling !*#%!
Date Wed, 20 Mar 2002 11:02:18 GMT
At 8:44 am -0500 19/3/02, Vadim Gritsenko wrote:
>> From: Jeremy Quinn [mailto:jeremy@media.demon.co.uk]
>>
>> At 7:59 am -0500 19/3/02, Vadim Gritsenko wrote:
>> >> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>> >>
>> >> From: "Jeremy Quinn" <jermq@media.demon.co.uk>
>> >>
>> >> > 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:sharkbait@mac.com>     		 <http://www.media.demon.co.uk>
   <phone:+44.[0].20.7737.6831>             <pager:jermq@vizzavi.net>

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message