Re: Problem with CGI::Carp under mod_perl

[Matt Sergeant <ma...@sergeant.org>]

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.

-- 
<Matt/>

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

Re: Problem with CGI::Carp under mod_perl

[Gunther Birznieks <gu...@extropia.com>]

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 (gunther.birznieks@extropia.com)
Extropia - The Web Technology Company
http://www.extropia.com/