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/
