You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by "T.J. Mather" <tj...@anidea.com> on 2000/11/30 06:37:25 UTC
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
Re: RFC: Apache::Carp - Error Handling under mod_perl
Posted by Matt Sergeant <ma...@sergeant.org>.
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/ **
\\//
//\\
// \\
Re: RFC: Apache::Carp - Error Handling under mod_perl
Posted by "Thomas J. Mather" <tj...@anidea.com>.
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.
Re: RFC: Apache::Carp - Error Handling under mod_perl
Posted by Gunther Birznieks <gu...@extropia.com>.
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: modperl-unsubscribe@apache.org
>For additional commands, e-mail: modperl-help@apache.org
__________________________________________________
Gunther Birznieks (gunther.birznieks@extropia.com)
eXtropia - The Web Technology Company
http://www.extropia.com/
Re: RFC: Apache::Carp - Error Handling under mod_perl
Posted by "Thomas J. Mather" <tj...@anidea.com>.
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.
Re: RFC: Apache::Carp - Error Handling under mod_perl
Posted by Gunther Birznieks <gu...@extropia.com>.
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 (gunther.birznieks@extropia.com)
eXtropia - The Web Technology Company
http://www.extropia.com/
Re: RFC: Apache::Carp - Error Handling under mod_perl
Posted by Matt Sergeant <ma...@sergeant.org>.
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/ **
\\//
//\\
// \\
Re: RFC: Apache::Carp - Error Handling under mod_perl
Posted by "Thomas J. Mather" <tj...@anidea.com>.
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?
Re: RFC: Apache::Carp - Error Handling under mod_perl
Posted by "Thomas J. Mather" <tj...@anidea.com>.
I forgot to include the Apache/Carp.pm attachment in my last e-mail.
Here it is.
Re: RFC: Apache::Carp - Error Handling under mod_perl
Posted by Gunther Birznieks <gu...@extropia.com>.
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: modperl-unsubscribe@apache.org
>For additional commands, e-mail: modperl-help@apache.org
__________________________________________________
Gunther Birznieks (gunther.birznieks@extropia.com)
eXtropia - The Web Technology Company
http://www.extropia.com/
Re: RFC: Apache::Carp - Error Handling under mod_perl
Posted by Dave Rolsky <au...@urth.org>.
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
==================*/