Re: Problem with CGI::Carp under mod_perl
At 09:49 AM 4/26/00 +0100, Steve Hay wrote:
> > [snip]
> >
> > Go into your CGI::Carp.pm file and look for the
> > ineval() method. Manually edit it to remove the 5.005 check and just
> > compile an ineval() routine that is dependent on longmess() instead of $^S.
>
>Thanks very much for your reply, this works a treat under 5.005_03 and also my
>new Perl 5.6.0 / mod_perl 1.23 / Apache 1.3.12 setup which I'm testing out.
>This is a great help to me. I hope the change makes it into CGI::Carp -- have
>you heard anything from the author yet?
Yes, I've heard from Lincoln Stein. The problem will likely be corrected in
the next release. The manner in which it will be fixed may be a little more
complicated.
In some of my testing, I found that perldoc -f die's recommended
$SIG{__DIE__} workaround of using $^S does not work if the die is inside of
a string -- such as
eval qq{die "something";};
Otherwise it would been useful to use a combination of $^S and looking at
the die message to make sure CGI::Carp is not improperly intercepting a top
level Apache::Registry eval.
Anyway, the bottom line is that the old method works in many of the cases,
but not all.
But it should work fine for you. It has worked great for me. Matt
Sergeant's Exception handling is also something to consider, but as I
posted previously, I believe (as a matter of coding philosophy which is
always the stuff of religious wars) that there is a difference between
exceptions and traditional fatal errors.
[snipped]
> >
> > This you cannot solve. Although CGI::Carp can catch fatal errors at script
> > startup because compile errors are fatal at that point. When a stirng is
> > eval'ed to compile the string into a set of data, though, those errors are
> > NOT fatal. They are warnings.
> >
> > Unfortunately, to get around this you would need to modify Apache::Registry
> > to trap warnings before compiling code and then die with a fatal error if
> > one of those warnings was a compile error.
>
>I can live without this, but it seems like an excellent idea. Any takers for
>doing it (I don't think I'm quite up to it myself...)?
>
I'll try and play with this later tonight... I've already done this for
myself as part of a toolkit for loading Extropia::View files written in
Perl since I wanted compile-time errors to be caught inside of the user
interface files since I thought it would be likely that graphic designers
would cause syntax errors fairly readily.
Later,
Gunther
__
Gunther Birznieks ([EMAIL PROTECTED])
Extropia - The Web Technology Company
http://www.extropia.com/
Re: Problem with CGI::Carp under mod_perl
Gunther Birznieks wrote: > At 02:02 PM 4/18/00 +0100, Steve Hay wrote: > > >I'm having problems using "CGI::Carp qw(fatalsToBrowser);" in modperl > >scripts. > > Sorry for the late reply. I was actually trying to figure out why you were > experiencing this problem. I rarely use Perl 5.005 specific features, and > so I actually received reasonable results where you were not. > > It turns out that CGI::Carp does a specific check for Perl 5.005 and above > and uses a different mechanism that asks whether it is in an eval block. > Unfortunately the $^S variable gives information that is not precisely the > same as the error string parsing (for "eval") technique in it's > effectiveness under mod_perl. > > [snip] > > Go into your CGI::Carp.pm file and look for the > ineval() method. Manually edit it to remove the 5.005 check and just > compile an ineval() routine that is dependent on longmess() instead of $^S. Thanks very much for your reply, this works a treat under 5.005_03 and also my new Perl 5.6.0 / mod_perl 1.23 / Apache 1.3.12 setup which I'm testing out. This is a great help to me. I hope the change makes it into CGI::Carp -- have you heard anything from the author yet? > >error_syntax.pl > >--- > > > > use CGI::Carp qw(fatalsToBrowser); > > $| = 1; > > print "Content-Type: text/html\n\n"; > > print "Syntax error at the end of this line ...\n" > > print "blah blah blah.\n"; > > > >Apache/CGI: > > > >Software error: > >Execution of d:/inetpub/cgi-bin/error_syntax.pl aborted due to > >compilation errors. > >For help, please send mail to the webmaster ([EMAIL PROTECTED]), > >giving this error message and the time and date of > >the error. > > > >Apache/modperl: > > > >Internal Server Error > >The server encountered an internal error or misconfiguration and was > >unable to complete your request. > >Please contact the server administrator, [EMAIL PROTECTED] and > >inform them of the time the error occurred, and > >anything you might have done that may have caused the error. > >More information about this error may be available in the server error > >log. > > This you cannot solve. Although CGI::Carp can catch fatal errors at script > startup because compile errors are fatal at that point. When a stirng is > eval'ed to compile the string into a set of data, though, those errors are > NOT fatal. They are warnings. > > Unfortunately, to get around this you would need to modify Apache::Registry > to trap warnings before compiling code and then die with a fatal error if > one of those warnings was a compile error. I can live without this, but it seems like an excellent idea. Any takers for doing it (I don't think I'm quite up to it myself...)? - Steve Hay
Re: Problem with CGI::Carp under mod_perl
At 02:02 PM 4/18/00 +0100, Steve Hay wrote: >I'm having problems using "CGI::Carp qw(fatalsToBrowser);" in modperl >scripts. Sorry for the late reply. I was actually trying to figure out why you were experiencing this problem. I rarely use Perl 5.005 specific features, and so I actually received reasonable results where you were not. It turns out that CGI::Carp does a specific check for Perl 5.005 and above and uses a different mechanism that asks whether it is in an eval block. Unfortunately the $^S variable gives information that is not precisely the same as the error string parsing (for "eval") technique in it's effectiveness under mod_perl. Of course, do take what I say with a grain of salt. I am NOT the author of CGI::Carp. But I do like using it because it is more convenient than using an outer eval block in every CGI script. I have emailed the author of CGI::Carp with this issue today and hopefully should receive confirmation or negation of this theory within the next few days unless others on here can confirm or deny the rumors. >Below are three short scripts and their output under Apache/CGI and >Apache/modperl. All three of them produce (more or >less) useful output under Apache/CGI, but only the last one does under >Apache/modperl. > >The first one calls die() itself. Under Apache/CGI the die() message >appears in the web browser (albeit preceded by a >spurious Content-Type line), but under Apache/modperl the message goes >to the error.log and a bizarre message appears in >the web browser consisting of some output from the script, followed by a >"200 OK" HTTP header, followed by a message >suggesting that all was not OK after all (all the same as if CGI::Carp >was not being used). > >The second one has a syntax error. Under Apache/CGI a message about a >compilation error appears in the web browser (but not >the detail of the syntax error itself, which disappears completely - not >even going to error.log!); under Apache/modperl an >"Internal Server Error" message appears in the web browser (again just >like CGI::Carp was not being used) and (curiously) >the detail of the syntax error does now at least appear in error.log! > >The third one attempts a division by zero and correctly says so in the >web browser under both Apache/CGI and >Apache/modperl. > >Can anybody explain what's going on here??? Yes. Albeit a little late. Sorry about that. >The first script is closest to the problem I've really got. I'm using >DBI/DBD::mysql and I want SQL syntax errors (which I >keep making) to appear in the web browser instead of having to keep >opening the error.log. Running under Apache/CGI I get >useful messages like: > >Software error: >DBD::mysql::st execute failed: You have an error in your SQL syntax near >'BINARY USER_NAME LIKE 'mk-%' LIMIT 10' at line 1 >at d:/inetpub/cgi-bin/mysql.pl line 300. > >but under Apache/modperl I just get useless garbage like the >error_die.pl below produces. > >I'm running Perl 5.005_03 / Apache 1.3.6 / mod_perl 1.22 on NT 4. > > >error_die.pl > > > use CGI::Carp qw(fatalsToBrowser); > $| = 1; > print "Content-Type: text/html\n\n"; > print "I'm about to die() ...\n"; > die "I'm dead.\n"; > >Apache/CGI: > >I'm about to die() ... Content-type: text/html >Software error: >I'm dead. >For help, please send mail to the webmaster ([EMAIL PROTECTED]), >giving this error message and the time and date of >the error. > >Apache/modperl: > >I'm about to die() ... HTTP/1.1 200 OK Date: Tue, 18 Apr 2000 11:09:35 >GMT Server: Apache/1.3.6 (Win32) mod_perl/1.22 >Connection: close Content-Type: text/html >OK >The server encountered an internal error or misconfiguration and was >unable to complete your request. >Please contact the server administrator, [EMAIL PROTECTED] and >inform them of the time the error occurred, and >anything you might have done that may have caused the error. >More information about this error may be available in the server error >log. This should work as you expected. The reason why it did not is because of the Perl 5.005 check. Go into your CGI::Carp.pm file and look for the ineval() method. Manually edit it to remove the 5.005 check and just compile an ineval() routine that is dependent on longmess() instead of $^S. >error_syntax.pl >--- > > use CGI::Carp qw(fatalsToBrowser); > $| = 1; > print "Content-Type: text/html\n\n"; > print "Syntax error at the end of this line ...\n" > print "blah blah blah.\n"; > >Apache/CGI: > >Software error: >Execution of d:/inetpub/cgi-bin/error_syntax.pl aborted due to >compilation errors. >For help, please send mail to the webmaster ([EMAIL PROTECTED]), >giving this error message and the time and date of >the error. > >Apache/modperl: > >Internal Server Error >The server encountered an internal error or misconfiguration and was >unable to complete your request. >Please contact the server administrator, [EMAIL PROTECTED] and >inform them of th
Re: Problem with CGI::Carp under mod_perl
At 12:46 PM 4/18/00 +0100, Matt Sergeant wrote: >On Tue, 18 Apr 2000, Steve Hay wrote: > > > I'm having problems using "CGI::Carp qw(fatalsToBrowser);" in modperl > scripts. > >Then don't use CGI::Carp. The whole qw(fatalsToBrowser) thing is broken, >IMHO, anyway. See http://modperl.sergeant.org/guide/exceptions.html for >a better way to handle exceptions. I looked at this today. I believe the problem started with Perl version 5.005 where Lincoln Stein started using $^S to detect if CGI::Carp is in an eval block. If you comment out that code and use the longmess() code inside of ineval() that is active for Perl versions below 5.005, fatalsToBrowser seems to work OK. I have emailed Lincoln Stein to confirm whether this makes sense. Although I only tested it in a few limited cases, so I don't know if 5.005 introduced new types of evaling that never existed in 5.004 where fatalsToBrowser worked fine. Only compile time errors are not caught. But that is as I stated in a previous message, because when you compile code in an eval, it is not a fatal error... it is a warning. I don't know if your guide is necessarily a "better" way to deal with errors than CGI::Carp when CGI::Carp actually works. ;) Although, I would concede it is a better way of dealing with exceptions. Important point that I would like to interject: Exceptions != Errors. die() by it's nature is not OO. It is a typical crash and dump because I got a fatal error type of situation. It is certainly idomatic to use die in a procedural way even in OO programs and exception handling is not always easier to read or understand even amongst experienced programmers of Perl (or even Java). Although Perl and Java are two different languages and arguably like comparing apples to oranges... I think it can be successfully argued that Java has had a lot more people looking at OO programming theory (and practice) because they were forced to by the language. So sometimes pulling out a Java article discussing a particular topic can help. In this case, Bill Venners (known for his articles on practical OO design) has the following article: http://www.javaworld.com/javaworld/jw-07-1998/jw-07-exceptions_p.html In it, Bill Venners discusses the difference between checked and unchecked exceptions. In essence, the theory is posed that errors are unchecked exceptions (this is the only error mechanism in Java). Typically what happens is that even in Java, most programmers do not bother with unchecked exceptions and allow them to bubble up the stack until the Java program dies. This is similar to what you expect in Perl for a truly fatal error. For generically checking fatal errors, I would at least posit that (when it works) CGI::Carp provides a useful tool so that you don't have to wrap the entire program in one huge eval block where uncaught errors would finally drop into the eval. The need to display fatal errors generically to a browser is not the same as constructive exception checking that programmers would do when looking for particular error conditions. Later, Gunther __ Gunther Birznieks ([EMAIL PROTECTED]) Extropia - The Web Technology Company http://www.extropia.com/
Re: Problem with CGI::Carp under mod_perl
At 06:38 PM 4/19/00 -0700, Perrin Harkins wrote:
> > > CGI::Carp can't catch compile errors.
> >
> > Oh. The CGI::Carp manpage says (regarding the use of "set_message()" to
> > control the output message): "In order to correctly intercept compile-time
> > errors, you should call set_message() from within a BEGIN{} block. ", which
> > suggests it does catch compile errors? I've tried both with "BEGIN
> > {set_message('...')}" and without a set_message() at all, but to no avail.
>
>My mistake. CGI::Carp doesn't catch compile errors inside an eval block,
>which is where you are when compiling under Apache::Registry. You could
>work around this by commenting out the first line of the die() subroutine
>where it checks to see if it's in an eval, but that's pretty lame and
>makes CGI::Carp incompatible with use of eval blocks. I don't use
>Apache::Registry or CGI::Carp, so I'm not very motivated to find a better
>fix. You could contact the author.
Actually I do not believe that this will help anyway. The reason being that
when you compile code in an eval, it is not a die error in the first place.
It ends up being a warning (so you need to trap the WARN signal).
To do this, Apache::Registry itself would need to be the one catching the
compilation error in a WARN signal and then outputting something to the
browser.
I don't know of a real way around this. However, I did spend some time
investigating these issues today and will post some of my results to
previous messages.
__
Gunther Birznieks ([EMAIL PROTECTED])
Extropia - The Web Technology Company
http://www.extropia.com/
Re: Problem with CGI::Carp under mod_perl
On Wed, 19 Apr 2000, Steve Hay wrote:
> > Sounds like a difference in the way CGI scripts and mod_perl buffer. I
> > fyou really want CGI::Carp to work, you need to make sure you don't send
> > any output before it gets called. Maybe you have PerlSendHeader on?
>
> I did have PerlSendHeader On: turning it off causes a DOS Prompt to pop up
> briefly, the die() message still goes to error.log and no output appears in
> the browser at all!
I've never used mod_perl on Windows, so I don't know what causes the DOS
prompt. Keep PerlSendHeader On, but suppress your output until the script
has completed (i.e. collect it in a scalar and then print it all at once).
CGI::Carp can't help you if you've already sent a bunch of stuff to the
browser. You don't have this problem with mod_cgi because it buffers
everything until the script finishes.
> > CGI::Carp can't catch compile errors.
>
> Oh. The CGI::Carp manpage says (regarding the use of "set_message()" to
> control the output message): "In order to correctly intercept compile-time
> errors, you should call set_message() from within a BEGIN{} block. ", which
> suggests it does catch compile errors? I've tried both with "BEGIN
> {set_message('...')}" and without a set_message() at all, but to no avail.
My mistake. CGI::Carp doesn't catch compile errors inside an eval block,
which is where you are when compiling under Apache::Registry. You could
work around this by commenting out the first line of the die() subroutine
where it checks to see if it's in an eval, but that's pretty lame and
makes CGI::Carp incompatible with use of eval blocks. I don't use
Apache::Registry or CGI::Carp, so I'm not very motivated to find a better
fix. You could contact the author.
- Perrin
Re: Problem with CGI::Carp under mod_perl
Perrin Harkins wrote:
> On Tue, 18 Apr 2000, Steve Hay wrote:
>
> > The first one calls die() itself.
> [...]
>
> Sounds like a difference in the way CGI scripts and mod_perl buffer. I
> fyou really want CGI::Carp to work, you need to make sure you don't send
> any output before it gets called. Maybe you have PerlSendHeader on?
I did have PerlSendHeader On: turning it off causes a DOS Prompt to pop up
briefly, the die() message still goes to error.log and no output appears in
the browser at all!
> > The second one has a syntax error.
> [...]
>
> CGI::Carp can't catch compile errors.
Oh. The CGI::Carp manpage says (regarding the use of "set_message()" to
control the output message): "In order to correctly intercept compile-time
errors, you should call set_message() from within a BEGIN{} block. ", which
suggests it does catch compile errors? I've tried both with "BEGIN
{set_message('...')}" and without a set_message() at all, but to no avail.
- Steve Hay
Re: Problem with CGI::Carp under mod_perl
On Tue, 18 Apr 2000, Steve Hay wrote: > I'm having problems using "CGI::Carp qw(fatalsToBrowser);" in modperl > scripts. [...] > The first one calls die() itself. Under Apache/CGI the die() message > appears in the web browser (albeit preceded by a > spurious Content-Type line), but under Apache/modperl the message goes > to the error.log and a bizarre message appears in > the web browser consisting of some output from the script, followed by a > "200 OK" HTTP header, followed by a message > suggesting that all was not OK after all (all the same as if CGI::Carp > was not being used). Sounds like a difference in the way CGI scripts and mod_perl buffer. I fyou really want CGI::Carp to work, you need to make sure you don't send any output before it gets called. Maybe you have PerlSendHeader on? > The second one has a syntax error. Under Apache/CGI a message about a > compilation error appears in the web browser (but not > the detail of the syntax error itself, which disappears completely - not > even going to error.log!); under Apache/modperl an > "Internal Server Error" message appears in the web browser (again just > like CGI::Carp was not being used) and (curiously) > the detail of the syntax error does now at least appear in error.log! CGI::Carp can't catch compile errors. - Perrin
Problem with CGI::Carp under mod_perl
Sorry! Here it is again in text/plain this time... (My mail client doesn't ask whether I want to send in text or HTML, hence the slip. Maybe *I* should get a new one!) --- I'm having problems using "CGI::Carp qw(fatalsToBrowser);" in modperl scripts. Below are three short scripts and their output under Apache/CGI and Apache/modperl. All three of them produce (more or less) useful output under Apache/CGI, but only the last one does under Apache/modperl. The first one calls die() itself. Under Apache/CGI the die() message appears in the web browser (albeit preceded by a spurious Content-Type line), but under Apache/modperl the message goes to the error.log and a bizarre message appears in the web browser consisting of some output from the script, followed by a "200 OK" HTTP header, followed by a message suggesting that all was not OK after all (all the same as if CGI::Carp was not being used). The second one has a syntax error. Under Apache/CGI a message about a compilation error appears in the web browser (but not the detail of the syntax error itself, which disappears completely - not even going to error.log!); under Apache/modperl an "Internal Server Error" message appears in the web browser (again just like CGI::Carp was not being used) and (curiously) the detail of the syntax error does now at least appear in error.log! The third one attempts a division by zero and correctly says so in the web browser under both Apache/CGI and Apache/modperl. Can anybody explain what's going on here??? The first script is closest to the problem I've really got. I'm using DBI/DBD::mysql and I want SQL syntax errors (which I keep making) to appear in the web browser instead of having to keep opening the error.log. Running under Apache/CGI I get useful messages like: Software error: DBD::mysql::st execute failed: You have an error in your SQL syntax near 'BINARY USER_NAME LIKE 'mk-%' LIMIT 10' at line 1 at d:/inetpub/cgi-bin/mysql.pl line 300. but under Apache/modperl I just get useless garbage like the error_die.pl below produces. I'm running Perl 5.005_03 / Apache 1.3.6 / mod_perl 1.22 on NT 4. error_die.pl use CGI::Carp qw(fatalsToBrowser); $| = 1; print "Content-Type: text/html\n\n"; print "I'm about to die() ...\n"; die "I'm dead.\n"; Apache/CGI: I'm about to die() ... Content-type: text/html Software error: I'm dead. For help, please send mail to the webmaster ([EMAIL PROTECTED]), giving this error message and the time and date of the error. Apache/modperl: I'm about to die() ... HTTP/1.1 200 OK Date: Tue, 18 Apr 2000 11:09:35 GMT Server: Apache/1.3.6 (Win32) mod_perl/1.22 Connection: close Content-Type: text/html OK The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, [EMAIL PROTECTED] and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. error_syntax.pl --- use CGI::Carp qw(fatalsToBrowser); $| = 1; print "Content-Type: text/html\n\n"; print "Syntax error at the end of this line ...\n" print "blah blah blah.\n"; Apache/CGI: Software error: Execution of d:/inetpub/cgi-bin/error_syntax.pl aborted due to compilation errors. For help, please send mail to the webmaster ([EMAIL PROTECTED]), giving this error message and the time and date of the error. Apache/modperl: Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, [EMAIL PROTECTED] and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. error_divide.pl --- use CGI::Carp qw(fatalsToBrowser); $| = 1; print "Content-Type: text/html\n\n"; print "I'm about to divide by zero ...\n"; my $x = 1 / 0; Apache/CGI: Software error: Illegal division by zero at d:/inetpub/cgi-bin/error_divide.pl line 5. For help, please send mail to the webmaster ([EMAIL PROTECTED]), giving this error message and the time and date of the error. Apache/modperl: Software error: Illegal division by zero at d:/inetpub/cgi-bin/error_divide.pl line 5. For help, please send mail to the webmaster ([EMAIL PROTECTED]), giving this error message and the time and date of the error.
Re: Problem with CGI::Carp under mod_perl
On Tue, 18 Apr 2000, Steve Hay wrote: > I'm having problems using "CGI::Carp qw(fatalsToBrowser);" in modperl scripts. Then don't use CGI::Carp. The whole qw(fatalsToBrowser) thing is broken, IMHO, anyway. See http://modperl.sergeant.org/guide/exceptions.html for a better way to handle exceptions. -- Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Problem with CGI::Carp under mod_perl
I'm having problems using "CGI::Carp qw(fatalsToBrowser);" in modperl scripts. Below are three short scripts and their output under Apache/CGI and Apache/modperl. All three of them produce (more or less) useful output under Apache/CGI, but only the last one does under Apache/modperl. The first one calls die() itself. Under Apache/CGI the die() message appears in the web browser (albeit preceded by a spurious Content-Type line), but under Apache/modperl the message goes to the error.log and a bizarre message appears in the web browser consisting of some output from the script, followed by a "200 OK" HTTP header, followed by a message suggesting that all was not OK after all (all the same as if CGI::Carp was not being used). The second one has a syntax error. Under Apache/CGI a message about a compilation error appears in the web browser (but not the detail of the syntax error itself, which disappears completely - not even going to error.log!); under Apache/modperl an "Internal Server Error" message appears in the web browser (again just like CGI::Carp was not being used) and (curiously) the detail of the syntax error does now at least appear in error.log! The third one attempts a division by zero and correctly says so in the web browser under both Apache/CGI and Apache/modperl. Can anybody explain what's going on here??? The first script is closest to the problem I've really got. I'm using DBI/DBD::mysql and I want SQL syntax errors (which I keep making) to appear in the web browser instead of having to keep opening the error.log. Running under Apache/CGI I get useful messages like: Software error: DBD::mysql::st execute failed: You have an error in your SQL syntax near 'BINARY USER_NAME LIKE 'mk-%' LIMIT 10' at line 1 at d:/inetpub/cgi-bin/mysql.pl line 300. but under Apache/modperl I just get useless garbage like the error_die.pl below produces. I'm running Perl 5.005_03 / Apache 1.3.6 / mod_perl 1.22 on NT 4. error_die.pl use CGI::Carp qw(fatalsToBrowser); $| = 1; print "Content-Type: text/html\n\n"; print "I'm about to die() ...\n"; die "I'm dead.\n"; Apache/CGI: I'm about to die() ... Content-type: text/html Software error: I'm dead. For help, please send mail to the webmaster ([EMAIL PROTECTED]), giving this error message and the time and date of the error. Apache/modperl: I'm about to die() ... HTTP/1.1 200 OK Date: Tue, 18 Apr 2000 11:09:35 GMT Server: Apache/1.3.6 (Win32) mod_perl/1.22 Connection: close Content-Type: text/html OK The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, [EMAIL PROTECTED] and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. error_syntax.pl --- use CGI::Carp qw(fatalsToBrowser); $| = 1; print "Content-Type: text/html\n\n"; print "Syntax error at the end of this line ...\n" print "blah blah blah.\n"; Apache/CGI: Software error: Execution of d:/inetpub/cgi-bin/error_syntax.pl aborted due to compilation errors. For help, please send mail to the webmaster ([EMAIL PROTECTED]), giving this error message and the time and date of the error. Apache/modperl: Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, [EMAIL PROTECTED] and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. error_divide.pl --- use CGI::Carp qw(fatalsToBrowser); $| = 1; print "Content-Type: text/html\n\n"; print "I'm about to divide by zero ...\n"; my $x = 1 / 0; Apache/CGI: Software error: Illegal division by zero at d:/inetpub/cgi-bin/error_divide.pl line 5. For help, please send mail to the webmaster ([EMAIL PROTECTED]), giving this error message and the time and date of the error. Apache/modperl: Software error: Illegal division by zero at d:/inetpub/cgi-bin/error_divide.pl line 5. For help, please send mail to the webmaster ([EMAIL PROTECTED]), giving this error message and the time and date of the error.
