I do use SIGWARN and SIGDIE handlers in my CGI::App projects, but the aren't really what you'd call "well integrated" with the CGI end of my projects. As much as it would be cool to call template-generating/displaying code from a sig handler to let the user know something has blown up, I've wanted to keep the error handling in my app as generic as possible, so if/when I write non-web interfaces for the code, I don't have to change anything in my error handling stuff.
It's pretty basic. I take a two pronged approach. First, I've written two functions, csWarn and csDie, that developers (only me at the moment) use instead of warn() and die() in their code. These take more detailed information then just a list of strings, namely information on error type, severity, a short message and debugging information. These write the information, along with a timestamp, to an error log. I also write SIG handlers that write to the same log, filling in the error type as UNTRAPPED and the the severity as MILD for SIGWARN, and CRITICAL for SIGDIE, and I dump $! and caller() into the debug field. Dumping these things into my own log file is handy because it separates it from the web server error messages like 404's, interrupted pipes, etc. I also set some configuration variables in a tied hash in such a way that I can have multiple log files for different parts of the site (or different subdomains), a way to further isolate errors from different parts of the site. I should note that I rarely use csDie() in my code. Since die and csDie both kill the program, and the handler doesn't do much more than print to a log, it kills the program before I can properly handle the error in the eyes of the user. So for things that ought to be fatal I use csWarn() but use a severity level of SEVERE or CRITICAL (if you're wondering, my severity levels are MILD,MODERATE,SEVERE, and CRITICAL). Then I have the subroutine that calls csWarn return a false value or something that lets me know that there was a mistake. -Stephen -----Original Message----- From: Mark Stosberg [mailto:[EMAIL PROTECTED]] Sent: Sunday, December 30, 2001 01:29 PM To: CGI::App list Subject: RE: [cgiapp] proposal for enhancement: error handling for load_tmpl()andother failures On Sun, 30 Dec 2001, Stephen Howard wrote: > In general I tend to be in the camp of wanting modules I use to return error >indicators to my code rather than dying noisily. The > more it can tell me "hey, you screwed up" without taking down the entire script, the >better. I'm _not_ a fan of modules who use > Carp and the like internally, as they often overwrite SIGWARN and SIGDIE handlers I >use in my own code, which is annoying and > counter-productive. Stephen, Do you use SIGWARN AND SIGDIE handlers in any of your CGI::App projects? Could you post a snippet? I'm interested to see how that might work out. -mark > > -Stephen > > -----Original Message----- > From: Mark Stosberg [mailto:[EMAIL PROTECTED]] > Sent: Sunday, December 30, 2001 11:14 AM > To: Greg Marr > Cc: CGI::App list > Subject: Re: [cgiapp] proposal for enhancement: error handling for > load_tmpl()and other failures > > > On Sun, 30 Dec 2001, Greg Marr wrote: > > > > I was just working with CGI::App today and ran into a situation I've > > > run into several times before: I got an internal server error because > > a > > > template could not be found when load_tmpl() was called. It would be > > > nice if CGI::App could systematically address this issue by providing > > > some error handling for this case. > > > > use CGI::Carp qw(fatalsToBrowser); > > Thanks Greg. > > I suppose in the case where I want to see the errors in development, but > not in production, this could be a fine solution. (which is most of what > I want, personally). For production use, this has the drawback of not > supporting templates as well, but it would still get the job done. > > -mark > http://mark.stosberg.com/ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > http://mark.stosberg.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
