On Wed, 11 Aug 2004, Jason A. Crome wrote: > What have others done? What would you do in my place? I'm curious to hear, > because this is starting to drive me nuts ;)
For Krang (http://krang.sf.net) we came up with a rather novel error handling system that seemed to work well and required no code in the individual run-modes to implement. Here's how it worked: - When an error occurs the code that finds the error calls Krang::Message::add_message() with a message identifier from conf/messages.conf indicating what went wrong. - Krang::Message puts the message on a stack in the user's session (managed by Apache::Session, of course). - The code then returns to the user, sometimes showing them the same form and sometimes redirecting them elsewhere, maybe even to another script within Krang. - Krang::CGI (a CGI::Application super-class) populates a special loop with any pending error messages. This loop is in the global header.tmpl which is included on all Krang screens. Since the error messages are in the session it doesn't matter if this is a different CGI or the same one that caught the error message! This system worked very well, and it had a few important advantages that might not be obvious: - Errors caught deep in the API can be made visible in the UI without requiring catching code in the CGI layer. - Errors can be generated by one CGI and then shown on a screen from another CGI. - Abstracting the error messages in a single conf file allowed non-programmers to edit the message text, improving the user experience. Someday maybe there will be translations done using this mechanism. I've been meaning to write an article about this technique. Thanks for reminding me! -sam --------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
