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 13:33:23 GMT
At 1:51 pm +0100 20/3/02, Nicola Ken Barozzi wrote:
>From: "Jeremy Quinn" <>
>> 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
>> messages'.
>It's possible, the framework is all there, you just need to write the

Yea, of course .....

>Now I understand that *nobody* wants to care about doing this, because the
>cocoon webapp example is instead used as a template.
>Because of this, I started refactoring the examples to make it easier to get
>a bare bones Cocoon webapp.
>I will make more examples and stylesheets for as soon as the freeze is over.

This cleanup will really help ..... thanks for this.

>> 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.
>Of course.
>Since the handle errors *is* a pipeline, you can output what you want, even
>plain text.

I was confused by seeing two outputs.

>> 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 ;)
>It's normal, and even useful to the febugger of the app to have this
>You see right away what went wrong.
>But handle errors is only for *real* errors, not for predefined program
>Incorrect xml is part of the possible logic of your program, and you
>shouldn't handle it in this part of the pipeline, because of the problems
>outlined in previous mails.

I am getting the point.
I need to trap my own webapp's errors within my own webapp, not leave it up
to the sitemap.

>As you see, the current implementation prevented you from misusing the
>concept, and IMHO this shows good design.


>> 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.
>The possibility of setting per-pipeline buffer size will be addressed in the
>next dev cycle.

Yes, this is going to be an interesting addition.

>> >> 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
>> 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
>> 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.
>? Each pipeline can have its own handle-errors, and some samples already
>show this.
>See the sub/ samples for a hint.
>> >IMHO StreamGenerator may not be right for the job. If there is an error
>> >the xml it happens what you saw.
>> >But it never happens with normal requests, and it's with those in mind
>> >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 ;)
>The request processing should be done (and usually is) with objects rather
>than in the pipeline.

I like to think I am trying to find new ways of using the sitemap, rather
than abusing it ;)

But I get your point ...

>Your needs are new to me, and highlight a possible deficiency in the
>handling of xml coming in.
>If we SAX away with it, we go in handle-errors.
>If we parse before, we do it twice.


>IMO this is the point.

I am validating twice, the form initially gets sent to the 'preview'
behaviour, where the user gets to see what changes they made and see what
the validator thought of it, they have to submit the hidden for again (this
time to the 'put' behaviour) to get the changes committed.

Is this what you mean by "If we parse before, we do it twice"?

>> >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
>> other internally. If these internal pipelines could report errors in a
>> controlled way, it would be much easier to control the response.
>This is a *very* interesting point.
>You are using sitemaps as flowmaps.

Kind of I guess ....

>Flowmaps should solve your problems but...
>yes, we need to think of how to handle errors with flowmaps, remembering
>that we should be able to make
>> Thanks for your help and effort.
>Thank you for slash edit.
>I think it's very cool :-)

I stand on the shoulders of others.

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