From: "Peter Robins" <[EMAIL PROTECTED]>
> Nicola, istm you are making 2 false assumptions:
> 1. all errors are program errors
> 2. only the people who set up the site use it
No, I don't make these assumptions, really.
1. All errors that are in the defined flow of the session must be handled
*without* handle-errors, which should handle what the developr hasen't
thought of. This is the assumption I have, and it could as well be wrong.
2. Not at all. The sample webapp is for site developers, not meant to be
shoved in production right away. If the site programmers don't take care of
providing nicer error messages, no wonder you have this idea.
> In any properly tested system, internal server errors and the like
shouldn't
> (!) occur.
How I would like it to be true! ;-)
> Even if they do, there is nothing the user can do about it, so
> there's no point in telling them, apart perhaps from a simple message that
> there's a problem - please try again later or whatever. If a user gets a
list
> of exceptions/java classes/whatever comes out of the generator, they won't
> understand a word of it anyway.
True. But what prevents the programmer to making the error more
human-readable?
The error can be fatal or simply an error for example. The Programmer would
like to show two different pages for it. Hence the info of the Exception is
needed.
> The site administrator needs a report, so the
> problem can be fixed, but will get that from the logs.
I prefer to leave this as a choice.
And sometimes, some non-db "transactions" need a rollback on error, like a
mail notification that something has gone wrong, and they may need info on
the kind of error to decide what to tell the user.
> In my experience, by far the commonest error is page not found, and by far
> the commonest cause of that is that the user has mistyped the url (or
clicked
> on an incorrect link). So all they need is a simple message saying 'page
not
> found, please check what you entered' - a simple read of an html file is
> surely the simplest way of doing this.
Sure, you can do it.
Make a stylesheet that outputs only that page in the handle-errors pipeline
and you're done.
> More user-friendly is to give them the
> message together with a standard menu of links to click on, which is why I
> was wanting an aggregate, but I'm not really bothered which map element is
> used to provide the page, whatever makes most sense.
>
> HTH
>
> p.s. if the sitemap compiler could similarly provide a more user-friendly
> message such as 'sitemap won't compile - pls check your xml is valid'
instead
> of inscrutable messages about sitemap handlers, the amount of traffic in
this
> list should decline significantly :-)
:-)
I agree, and I'm working on a FAQBuilder, that gives more helpful messages
based on info from a FAQ.
I hope to commit it soon.
As I've read in also private responses, what the developers are missing is a
simple error page that says something descriptive about the error, with the
possibility of having a more detailed message, and a simple way of showing
an html page.
To be honest, this is already possible in current Cocoon, but it seems that
no developer that uses Cocoon touches the error handling stuff, so I need to
do it for them ;-P
The Cocoon webapp is a *sample*, not a template.
> p.p.s. don't have any arguments against your last point - TIA for any
> improvements
:-)
Thanks for the feedback! :-)
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>
