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/