RE: handling eval in ePerl
-Original Message-
From: Perrin Harkins [mailto:[EMAIL PROTECTED]]
My problem is that die works fine as such but it conks out if done
inside a eval.
Okay, I missed the part about eval() before. Take a look at this code
from Parse::ePerl::Evaluate() :
local $SIG{'__DIE__'} = sub { $error .= $_[0]; };
Yuck. People really need to stay away from $SIG{__DIE__} unless they
*really* know what they're doing.
Matt.
This e-mail has been scanned for all viruses by Star Internet. The service is powered
by MessageLabs. For more information on a proactive anti-virus service working around
the clock, around the globe, visit: http://www.star.net.uk
Re: handling eval in ePerl
Perrin Harkins wrote:
local $SIG{'__DIE__'} = sub { $error .= $_[0]; };
That's going to kill your exception handling code. You need to change
that if you want to be able to use eval() in your code. Matt has an
explanation of this in the exceptions part of the mod_perl Guide.
Hmm,
I think just commenting it worked !!. I have tried the following which
have worked the way it should.
---
# Exception handling
eval {die blah blah blah;};
print got : $@;
---
die blah blah blah;
---
# Write to error log
use Apache::Log;
Apache-request-log-error(got : $@);
---
# Syntax error
eval {die blah blah blah;
print got : $@;
---
print STDERR blah blah blah is going to the browser but I am not
really worried about it too much unless it is something I should worry
about - anyone care to comment on that ?
Ofcourse I still dont understand why die was being trapped out there.
Thanks to Perrin and Matt for their suggestions anyway.
Mithun
Re: handling eval in ePerl
print STDERR blah blah blah is going to the browser but I am not
really worried about it too much unless it is something I should worry
about - anyone care to comment on that ?
Printing error messages to the public is a potential security risk, so
you have to decide how paranoid you want to be. You could change this
behavior by modifying the tied STDERR in Parse::ePerl or maybe in
Apache::ePerl where it prints the message to the browser.
Ofcourse I still dont understand why die was being trapped out there.
It is being trapped to allow for error reporting and to avoid leaving
the program in an unknown state when a problem occurs. If you want it
to still work for this but not pick up your eval() calls, you can
replace the __DIE__ handler there with something fancier like this:
local $SIG{__DIE__} = sub {
my $in_eval = 0;
for( my $stack = 1; my $sub = (CORE::caller($stack))[3];
$stack++ ) {
$in_eval = 1 if $sub =~ /^\(eval\)/;
}
$error .= $_[0] unless $in_eval;
};
This is a slight variation of some Michael Schwern code that Stas posted
a little while ago.
- Perrin
Re: handling eval in ePerl
On Mon, 21 Jan 2002, Mithun Bhattacharya wrote:
Perrin Harkins wrote:
Umm I didnt mean to offend anyone in my previous posting - I did say I
probably hadnt presented my situation properly.
I don't think anyone was offended. Perrin was just trying to help you see
why people might not have replied. That's what I got from the tone anyway.
The Apache::ePerl code is very simple, and I suggest you read it at some
point. It attempts to eval() your code, and does the behavior you saw
if it fails (which is what happens when your script does a die()). I
don't think you can change that without changing the code, but that's
pretty easy to do.
My problem is that die works fine as such but it conks out if done
inside a eval.
--
%
die blah blah blah;
%
--
redirects me to the default error page.
--
%
eval {die blah blah blah;};
%
--
on the other hand says the following.
--
Apache::ePerl
Version 2.0214
ERROR:
Error on evaluating script from P-code
Contents of STDERR channel:
blah blah blah at //test.html line 2.
--
It looks to me like the generated code that ePerl is trying to eval is
bad. That seems like it's most likely this is an actual ePerl problem, and
so the only thing I can suggest is you hack the ePerl code to actually
display $@ when the evaluation of the script from P-code occurs (why on
earth aren't they doing that already??). Also I suggest while you're in
there, have it print the script to STDERR before doing the eval, so you
can check the error log and see what ePerl thinks your parsed script looks
like.
I am not sure why that might be considered acceptable response but it
really makes my code a lot more messier trying to circumvent that.
If I could have fixed Apache::ePerl I wouldnt be asking the question
here - I usually dont go around asking questions to show people how much
I know about anything. I am not asking to be spoonfed or something but
if there is something which can be done without changing the
Apache::ePerl code I would opt for that. It feels like being told to
change gcc's code if my C code is not working :) - yah both of them are
written in C .
The difference being that gcc is maintained, so you might stand a cat in
hell's chance of some help from the authors or getting a bug fix.
Unfortunately ePerl isn't maintained, so you have to open the bonnet (hood
to USians) and fix things yourself.
--
!-- Matt --
:-Get a smart net/:-
Re: handling eval in ePerl
Umm I didnt mean to offend anyone in my previous posting - I did say I
probably hadnt presented my situation properly.
No problem, I just meant don't give up so quickly.
Ofcourse you noticed I wrote ePerl/EmbPerl/Mason ?? I clubbed them
together since I assume among other things you can embed perl code in
HTML using either of them.
You can, but they don't share any code with ePerl.
My problem is that die works fine as such but it conks out if done
inside a eval.
Okay, I missed the part about eval() before. Take a look at this code
from Parse::ePerl::Evaluate() :
local $SIG{'__DIE__'} = sub { $error .= $_[0]; };
That's going to kill your exception handling code. You need to change
that if you want to be able to use eval() in your code. Matt has an
explanation of this in the exceptions part of the mod_perl Guide.
It feels like being told to
change gcc's code if my C code is not working :) - yah both of them
are
written in C .
Apache::ePerl is written in perl. It calls Parse::ePerl to do the dirty
work, and some of that is written in C, but not the part that's causing
you problems.
- Perrin
