cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <>
Subject Re: error handling !*#%!
Date Wed, 20 Mar 2002 10:50:42 GMT
At 2:26 pm +0100 19/3/02, Nicola Ken Barozzi wrote:
>From: "Jeremy Quinn" <>
>> At 11:08 am +0100 19/3/02, Nicola Ken Barozzi wrote:
>> >From: "Jeremy Quinn" <>
>> >
>> >
>> >> Dear All,
>> >>
>> >> I am totally mystified as to how you are supposed to handle errors in
>> >> webapps built using Cocoon.


Sorry for my late reply, I was teaching yesterday and not supposed to be
doing my email ;) (Some of my students got their first Cocoon websites up,

>> >Dear Jeremy,
>> > this is a known issue, and basically a worksforme.

>> Ah, can I redirect on error internally and still have the original Request
>> available?
>Redirects are not allowed IIRC, or shouldn't be.
>They can cause loops, because where you redirect can have errors too.

Hmm, redirect to a different pipeline that reads the request data as text
this time, sends it back to the user as a form, using
'disable-output-escaping' so the mal-formed XML comes back intact. Then you
loose the error message .... hmmm

>> Basically I am trying to send sensible response when StreamGenerator
>> exceptions on mal-formed XML.
>Well, there shouldn't be malformed XML being processed.

That is the very point I am wanting to make.

In a publishing engine, this is indeed the case. In a webapp, not so sure,
in an online editor, no choice mate, we need to check well-formedness

Anyone got any well-formedness checking javascripts? ;)

>> >If you have a better solution, please commit it, we are all waiting.
>> Yea, sorry if I was rude !
>> I accept what you say ..... I think that the current error-handling is ok
>> for publishing, but not good enough for webapps ......
>Well, AFAIK, it's not enough yet, but getting better.
>I haven't had much help on it, and little feedback. I'm happy we can discuss
>about how to make it become better :-)

Thanks ..... one idea is that we might like the concept of different error
reporting for different users.

ie. during development, a Java developer would have all stacktraces
reported, an XSLT developer may have their dev environment set up to just
report Parsing and Transformation errors. A production server would have
all 'technical' error reporting turned off and would just send 'polite

Another issue (I have not my head around yet) : can we report the error
'inline' somehow, instead of as a second 'document root', then people who
need to, could do something useful with it.

To see what I mean:

Grab <slash-edit/> from the scratchpad, fire it up. Using the 'Alpha'
Editor, make new page, add mal-formed XML (<br> would do), 'Preview' the
changes and Boom, you get two sequential pages! (OK, so I can make the
<slash-edit/> bit look better ;), but it was still a shock to see what
happens ;)

Another idea could be to say: this particular sitemap pipeline is a
"buffering error-collection pipeline" because this is a crucial part of my
webapp that /might/ throw exceptions that I want to adapt to.

>> Has anyone got examples they can send me of how they have implemented
>> error-handling in the sitemap, the samples are not very revealing .....
>To be honest, there's nothing much to it.

So no one documents it ;) (Sorry, I know it is as much my responsibility as
anyone else .....)

>In handle-errors you have a sitemap ther has a fixed Generator.
>You can use Actions, Transformers and a Serializer, like in other sitemaps.

What confused me I guess, was where the error report came out.

Plus I tried several times to put <map:handle-errors/> inside separate
<map:pipeline/>s and got compile errors and hangs.

>IMHO StreamGenerator may not be right for the job. If there is an error in
>the xml it happens what you saw.
>But it never happens with normal requests, and it's with those in mind that
>the error handling, as it is now, was created.

I understand.
I am fully prepared to write a new Generator that parses Requests and does
not throw exceptions. I was just trying to see if I could get away without
it ;)

>Please tell me what you want to do as a bigger picture so I can help you
>with a possible solution.

I never really needed to worry about what the error handlers did before,
like most people, all my errors were removed before publishing my sites.

It is only since starting <slash-edit/> and beginning to look to see what
was actually being sent that I got a bit shocked at the result.

The <slash-edit/> sitemap is broken down into small snippets that call each
other internally. If these internal pipelines could report errors in a
controlled way, it would be much easier to control the response.

Thanks for your help and effort.

regards Jeremy

   Jeremy Quinn                                           Karma Divers
                                                       webSpace Design
                                            HyperMedia Research Centre

   <>     		 <>
   <phone:+44.[0].20.7737.6831>             <>

To unsubscribe, e-mail:
For additional commands, email:

View raw message