|
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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~--- |
begin:vcard fn:Timothy Farrell n:Farrell;Timothy org:Statewide General Insurance Agency;IT adr:;;4501 East 31st Street;Tulsa;OK;74135;US email;internet:[EMAIL PROTECTED] title:Computer Guy tel;work:(918)492-1446 url:www.swgen.com version:2.1 end:vcard
