Thanks Tim,
this is very close to what I had in mind so I think this will go in.
But let me ask you for one change. Instead of
error_destinations = {
'400' : '/init/error/invalidPath',
'default' : '/init/static/defaulterror.html'
}
make it
routes_onerror = [
('init/400','/init/error/invalidPath'),
('*/*','/init/static/defaulterror.html'),
]
where 'appname/errno' can be '*/errno' 'appname/*' and '*/*'. Also
this should be a list for uniformity with routes_in and routes_out.
Internally you can convert it to dict with dict(list).
Can you do it?
Massimo
On Nov 3, 9:48 am, Timothy Farrell <[EMAIL PROTECTED]> wrote:
> Back to the ever-present issue of (better) error-handling. This time, I've
> got code!
> Anyway, to catch you guys up, we last left this at Massimo liking the idea of
> using @onerror decorators
> (http://mdp.cti.depaul.edu/AlterEgo/default/show/75) to trap errors. His
> reasoning is his own, but I think it had to do with the potential complexity
> of other proposed solutions. In general, I'm against using decorators for
> something that should be applied to all functions. Furthermore, it limits
> error-handling to that which happens inside controllers.
> So the solution I've coded works like this:
> in routes.py add this somewhere:error_destinations = {
> 400 : '/init/error/invalidPath'
> ,'default' : '/init/static/defaulterror.html'
> }
> The key is the HTTP status code for the error; the value is the redirected
> destination. Only HTTP codes >= 400 are valid, others are ignored. So in
> the above example, if any page errors with a 400 error, the user will be
> redirected (via HTTP 303 redirect)
> to/init/error/invalidPath?code=400&ticket=... You get the idea. If there is
> no entry for the error code returned, then the default error route will be
> used. If no default or specific code-handler exists, you will receive the
> normal error message the you are used to...or...
> I've also added the ability to specify the two default error pages.
> Currently they are hard-coded in main.py. I've moved the defaults from
> main.py to rewrite.py with the ability to be overwritten by specifying them
> in routes.py. Example:error_message_ticket='''\
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML
> 4.01//EN""http://www.w3.org/TR/html4/strict.dtd";>
> <html lang="en">
> <head>
> <title>Error generating page</title>
> </head>
> <body>Something bad happened...sorry. Ticket is: $(ticket)s</body>
> </html>'''
> error_message = error_message_ticket % dict(ticket="(not available)")
> Since routes.py is eval'ed, you could load this content from a separate file
> if you wish. To those familiar with the code, notice that I changed the
> error messages from iterative Python string templates to dictionary-based.
> Tough questions:
> 1) What happens if an error handler returns an error? - If it returns a
> different error than the one it is handling, error handling will redirect
> based on the new error. If it raises the same error it is handling at the
> same location, then the static error message (error_message) will be
> displayed.
> 2) Isn't there still the possibility for error-loops? Yes, but it's much
> less likely and will only happen because of developer coding errors rather
> than web2py. You would still get tickets saved, but the user will see a
> brower page about server loops. The only way around this right now is to
> depend on sessions which we cannot do since the app could session.forget
> them...right? But this is a moot point because your error-handlers will be
> rock-solid right!?
> So, what do you think? Have I missed any of the potential caveats? I
> haven't sent in any code because I'd like some community feedback first.
> -tim
>
> tfarrell.vcf
> < 1KViewDownload
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py Web Framework" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
