Re: RFC: Apache::Carp - Error Handling under mod_perl
On Fri, 1 Dec 2000, Gunther Birznieks wrote: The other thing that worries me is that even if you sneak the code back into the PageKit hierarchy you are still not doing everything Lincoln is doing to help deal with eval issues. This is a particularly thorny problem (and I suspect part of the reason why Matt wants CGI::Carp to die ... no pun intended). The reason I want it to die is that it doesn't deal with the eval issues. It may try to. But it doesn't succeed. -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: Apache::Carp - Error Handling under mod_perl
Can you help by explaining what this does that is different from CGI::Carp? What are you doing that is Apache specific? Could CGI::Carp do the job? If there was something you needed added to CGI::Carp, would it make sense for you to add the apache-specific function flag to CGI::Carp instead of making a brand-new module? At 12:37 AM 11/30/00 -0500, T.J. Mather wrote: I've done a lot of programming under mod_perl and I got tired of examining the error logs for errors. So I wrote a module that displays to the broswer the error (with a complete call stack) for any fatals or warnings that occur on a development server (similar to using CGI::Carp qw(fatalsToBrowser);), or emails the site administrator for errors on a production server. This has been released on CPAN as Apache::PageKit::Error, but since it doesn't depend on Apache::PageKit at all, I'm thinking of releasing it as a seperate module. Do you think this is worth doing? What should it be called? Is Apache::Carp a good name? Documentation can be found here (with the old Apache::PageKit::Error name) http://search.cpan.org/doc/TJMATHER/Apache-PageKit-0.05/lib/Apache/PageKit/Error.pm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Web Technology Company http://www.extropia.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: Apache::Carp - Error Handling under mod_perl
On Thu, 30 Nov 2000, Gunther Birznieks wrote:
Can you help by explaining what this does that is different from CGI::Carp?
What are you doing that is Apache specific? Could CGI::Carp do the job? If
there was something you needed added to CGI::Carp, would it make sense for
you to add the apache-specific function flag to CGI::Carp instead of making
a brand-new module?
Can we not burn CGI::Carp yet? :-)
I'm assuming this new module is also based on $SIG{__DIE__}... in which
case, shoot me now.
--
Matt/
/||** Director and CTO **
//||** AxKit.com Ltd ** ** XML Application Serving **
// ||** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** Personal Web Site: http://sergeant.org/ **
\\//
//\\
// \\
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: Apache::Carp - Error Handling under mod_perl
Sure. I have attached Apache/Carp.pm, so you can examine it. Some of the main differences that can't be implemented easily under CGI are: * Apache::Carp can be configured in the httpd.conf file to send an e-mail to the server admin by setting 'PerlSetVar APACHE_CARP_HANDLER email'. This way you can easily configure e-mail error notices on production servers and displayed error notices on development servers, _without_ changing Perl code base. This is very useful when you have production and development servers running off of the same CVS tree. * It displays the Apache handler that the error occurred under by using $r-current_callback Some other features that make it different from CGI::Carp include: * Can send e-mail notices - very useful for production servers. * Displays complete call stack even for warns and dies. * Displays user, host, remote_host, and referer (useful for email notices) On Thu, 30 Nov 2000, Gunther Birznieks wrote: Can you help by explaining what this does that is different from CGI::Carp? What are you doing that is Apache specific? Could CGI::Carp do the job? If there was something you needed added to CGI::Carp, would it make sense for you to add the apache-specific function flag to CGI::Carp instead of making a brand-new module? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: Apache::Carp - Error Handling under mod_perl
I forgot to include the Apache/Carp.pm attachment in my last e-mail.
Here it is.
package Apache::Carp;
# $Id: $
use integer;
use strict;
use Mail::Mailer;
# trap die and warn
$main::SIG{__WARN__} = \Apache::Carp::warn;
$main::SIG{__DIE__} = \Apache::Carp::die;
$Apache::Carp::in_use = 'yes';
sub errorMessage {
return if $Apache::Carp::in_use eq 'no';
my $r = Apache-request;
my $s = Apache-server;
return unless $r;
if($r-dir_config('APACHE_CARP_HANDLER') eq 'email'){
my $uri = (split(' ',$r-the_request))[1];
$uri .= '?' . $r-notes('query_string') if $uri !~ /\?/;
my $userID = $r-connection-user;
my $host = $r-header_in('Host');
my $remote_host = $r-header_in('X-Forwarded-For') || $r-get_remote_host;
my $referer = $r-header_in('Referer');
my $current_callback = $r-current_callback;
my $message = END;
$uri
userID: $userID host: $host remote_host: $remote_host referer: $referer
handler: $current_callback
$_[0]
END
my $i = 0;
while (my ($package, $filename, $line, $subr) = caller($i)){
$message .= "stack $i: $package $subr line $line\n";
$i++;
}
my $mailer = new Mail::Mailer;
$mailer-open({To = $s-server_admin,
Subject = "Website $_[1]"
});
print $mailer $message;
$mailer-close;
} elsif ($r-dir_config('APACHE_CARP_HANDLER') eq 'display') {
my $color = $_[1] eq 'WARN' ? 'blue' : 'red';
my $message = $_[0];
$message =~ s//lt;/g;
$message =~ s//gt;/g;
print qq{prefont color="$color"$_[1]: $message};
my $i = 0;
while (my ($package, $filename, $line, $subr) = caller($i)){
print "stack $i: $package $subr line $line\n";
$i++;
}
print qq{/font/prebr};
}
}
sub warn {
errorMessage($_[0],"WARN");
}
sub die {
errorMessage($_[0],"FATAL");
}
1;
__END__
=head1 NAME
Apache::Carp - Error Handling under mod_perl
=head1 SYNOPSIS
In your perl code or Cstartup.pl file:
use Apache::Carp;
In your Apache configuration file:
PerlSetVar APACHE_CARP_HANDLER email
=head1 DESCRIPTION
Redirects warnings and fatal errors to screen or e-mail by using
C__WARN__ and C__DIE__ signal handlers. Includes detailed information
including error message, call stack, uri, host, remote host, remote user,
referrer, and handler.
If CAPACHE_CARP_HANDLER is set to Idisplay, errors will be
displayed on the screen for easy debugging. This should be used in a development
environment only.
If CAPACHE_CARP_HANDLER is set to Iemail, errors will be e-mailed to the site
adminstrator as specified in the Apache CServerAdmin configuration directive.
This should be used on a production site.
=head1 AUTHOR
T.J. Mather ([EMAIL PROTECTED])
=head1 COPYRIGHT
Copyright (c) 2000, AnIdea Corporation. All rights Reserved.
=head1 LICENSE
This program is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY;
without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
See the Ricoh Source Code Public License for more details.
You can redistribute this module and/or modify it only under the terms of the Ricoh
Source Code Public License.
You should have received a copy of the Ricoh Source Code Public License along with
this program; if not, obtain one at http://www.pagekit.org/license
=cut
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: Apache::Carp - Error Handling under mod_perl
OK, I can see the advantage of the Apache specific stuff. However, in looking at your code, I think you may not be taking into account a lot of eval logic that CGI::Carp has. Eval logic is the hardest to get right (and I bet there are still bugs) because SIG die is still called within an eval. But some evals are "OK" -- for example Apache::Registry scripts are essentially the result of evaling. Also, you don't appear to be catching croak, carp, and confess. It's not necessarily obvious if you really want a full stack trace for all dies. It usually makes sense for the programmer to choose the stack trace method. These things are taken care of in CGI::Carp. However, with that said, I think your code could make use of CGI::Carp and wrap around it with similar effect. As for sending email... You do know that there is a variable in CGI::Carp where you can set up a reference to a subroutine instead of using Lincoln Stein's right? This can be set up to email instead of or in conjunction with printing to the display. Anyway, I do think the Apache side is useful, but I question rewriting the logic of CGI::Carp when it looks like you could be making use of it as either a subclass or a containment. At 11:08 AM 11/30/00 -0500, Thomas J. Mather wrote: Sure. I have attached Apache/Carp.pm, so you can examine it. Some of the main differences that can't be implemented easily under CGI are: * Apache::Carp can be configured in the httpd.conf file to send an e-mail to the server admin by setting 'PerlSetVar APACHE_CARP_HANDLER email'. This way you can easily configure e-mail error notices on production servers and displayed error notices on development servers, _without_ changing Perl code base. This is very useful when you have production and development servers running off of the same CVS tree. * It displays the Apache handler that the error occurred under by using $r-current_callback Some other features that make it different from CGI::Carp include: * Can send e-mail notices - very useful for production servers. * Displays complete call stack even for warns and dies. * Displays user, host, remote_host, and referer (useful for email notices) On Thu, 30 Nov 2000, Gunther Birznieks wrote: Can you help by explaining what this does that is different from CGI::Carp? What are you doing that is Apache specific? Could CGI::Carp do the job? If there was something you needed added to CGI::Carp, would it make sense for you to add the apache-specific function flag to CGI::Carp instead of making a brand-new module? __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Web Technology Company http://www.extropia.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: Apache::Carp - Error Handling under mod_perl
OK, I think Apache::Carp was a misleading name - it is not really a replacement for CGI::Carp - instead it is a simple module for reporting errors under a mod_perl enviroment that is easy to use and doesn't require that the programmer use carp and croak. A better name would have been something like Apache::ErrorReport So, I think I will keep this bundled with the Apache-PageKit distribution as Apache::PageKit::Error, (although it will still work by itself), unless there is demand for a seperate Apache-ErrorReport distribution. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: Apache::Carp - Error Handling under mod_perl
I didn't mean for you to withdraw. I would encourage you to still make it Apache::Carp. But then to avoid confusion model it more after CGI::Carp while adding the features you wanted for Apache::PageKit. As a person who has hacked and debugged the internals of CGI::Carp and looking at your code, I think it is entirely doable for this to happen. As a user of CGI::Carp, I'd certainly like to see an Apache::Carp facility. As for not requiring the programmer to use croak and carp. To some degree I agree that it may be nice to override die with a stack traced die. But I know that when I program modules and applications I take special care to use croak, die, and confess in the different situations they were intended for. Anyway, you could offer both the stack traced die and the croak/confess/carp compatibility in the same fell swoop but just offer it as a config option. The other thing that worries me is that even if you sneak the code back into the PageKit hierarchy you are still not doing everything Lincoln is doing to help deal with eval issues. This is a particularly thorny problem (and I suspect part of the reason why Matt wants CGI::Carp to die ... no pun intended). You may not have experienced this problem because your PageKit hasn't run on top of so many different people's scripts and programming styles. CGI::Carp runs on a LOT of platforms and programming styles, so it's evolved to take care of them which you could/should be taking advantage of IMHO while still providing a benefit to the Apache community. Later, Gunther At 11:37 PM 11/30/2000 -0500, Thomas J. Mather wrote: OK, I think Apache::Carp was a misleading name - it is not really a replacement for CGI::Carp - instead it is a simple module for reporting errors under a mod_perl enviroment that is easy to use and doesn't require that the programmer use carp and croak. A better name would have been something like Apache::ErrorReport So, I think I will keep this bundled with the Apache-PageKit distribution as Apache::PageKit::Error, (although it will still work by itself), unless there is demand for a seperate Apache-ErrorReport distribution. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Web Technology Company http://www.extropia.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: Apache::Carp - Error Handling under mod_perl
Yes it would be useful to have an Apache::Carp as Gunther described it, but I don't really have the time right now to develop it. Maybe I'll get the time to later, but in the meanwhile, I'll stick with the current module in PageKit (it works well with code written under PageKit). If anybody else wants to take up the torch that would be great. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RFC: Apache::Carp - Error Handling under mod_perl
I've done a lot of programming under mod_perl and I got tired of examining the error logs for errors. So I wrote a module that displays to the broswer the error (with a complete call stack) for any fatals or warnings that occur on a development server (similar to using CGI::Carp qw(fatalsToBrowser);), or emails the site administrator for errors on a production server. This has been released on CPAN as Apache::PageKit::Error, but since it doesn't depend on Apache::PageKit at all, I'm thinking of releasing it as a seperate module. Do you think this is worth doing? What should it be called? Is Apache::Carp a good name? Documentation can be found here (with the old Apache::PageKit::Error name) http://search.cpan.org/doc/TJMATHER/Apache-PageKit-0.05/lib/Apache/PageKit/Error.pm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: Apache::Carp - Error Handling under mod_perl
On Thu, 30 Nov 2000, T.J. Mather wrote: I've done a lot of programming under mod_perl and I got tired of examining the error logs for errors. So I wrote a module that displays to the broswer the error (with a complete call stack) for any fatals or warnings that occur on a development server (similar to using CGI::Carp qw(fatalsToBrowser);), or emails the site administrator for errors on a production server. You might consider using Log::Dispatch to handle the errors. This would give you a lot of flexibility basically for free in terms of sending your outputs wherever you want as well as giving you log levels and such if you need it. Of course, I'm biased cause I wrote Log::Dispatch. -dave /*== www.urth.org We await the New Sun ==*/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
