hey, sorry for the long wait. In my Logs::Error module I have a begin block where I
declare my SIG handlers and install them. The
code is a bit old and I haven't done much other than add a few comments so you can
more easily tell what's going on:
BEGIN
{
sub csWarnHandle
{
#sig handler gets 'unset' after every call. this reinstalls.
$SIG{__WARN__} = \&csWarnHandle;
return if $^S;
my @input = @_;
my ($message,$debug) = ('','');
# I'm haven't explored thoroughly whether a non-user call to
# warn and die populate the latter slots in @_, but usually
# the last line of $_[0] is the "summary" message of an error:
my @first = split /\n/, $input[0];
if( scalar( @first ) > 1 )
{
$message = $first[-1];
$debug = "\n--------\n".join( "\n--------\n",@input );
}
else
{
$message = $first[-1];
}
my ($package,$filename,$line) = caller;
Log_Error(class=>'UNTRAPPED',
severity=>'MILD',
message=>$message,
debug=>"Package: $package\nFile: $filename\nLine Number:
$line$debug");
return 1;
}
sub csDieHandle
{
$SIG{__DIE__} = \&csDieHandle and return if $^S;
my @input = @_;
my ($message,$debug) = ('','');
my @first = split /\n/, $input[0];
if( scalar( @first ) > 1 )
{
$message = $first[-1];
$debug = "\n--------\n".join( "\n--------\n",@input );
}
else
{
$message = $first[-1];
}
my $i=0; my $callinfo='';
# the caller trace is quite useful, I haven't gone back and
# added it to the csWarnHandle sub yet though:
$debug .= "\n--------\nCaller Trace (package|file|line|sub):";
$debug .= "\n".$callinfo while( $callinfo = join(" | ",(caller($i++))[0..3]) );
my ($package,$filename,$line) = caller;
Log_Error(class=>'UNTRAPPED',
severity=>'CRITICAL',
message=>$message,
debug=>"Package: $package\nFile: $filename\nLine Number:
$line$debug");
exit(0);
}
$SIG{__WARN__} = \&csWarnHandle;
$SIG{__DIE__} = \&csDieHandle;
}
-----Original Message-----
From: Mark Stosberg [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 31, 2001 08:29 AM
To: Stephen Howard
Subject: RE: [cgiapp] proposal for enhancement: error handling for
load_tmpl()andother failures
Stephen,
Thanks for sharing that. It sounds like a really well designed system.
I'd be interested in seeing some code samples if that's possible. It's
been a long time since I wrote a signal handler and I'm a bit rusty. :)
-mark
On Mon, 31 Dec 2001, Stephen Howard wrote:
> 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]
>
http://mark.stosberg.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
