[Gllug] perl eval()

[Alain Williams]

On Thu, Jun 20, 2002 at 02:16:20PM +0100, will wrote:
> Alain Williams wrote:
> > On Thu, Jun 20, 2002 at 12:22:03PM +0100, will wrote:
> > 
> >>Hi all,
> >>
> >>A bit OT but this seems like the best place to ask.
> >>
> >>I have been experimenting with the perl DBI the last couple of days and have come upon a bit of a 
> >>problem.  I need to trap the errors returned when doing things like connecting to the database as I 
> >>don't want the script to die if there was an error.  The only way to do it that I have found so far 
> >>however is to wrap the piece of code that might fail in eval() 
> >>(http://search.cpan.org/doc/JWIED/Msql-Mysql-modules-1.2219/mysql/lib/DBD/mysql.pm).  In Perl in a 
> >>Nutshell it says about eval():
> >>
> >>"Evaluates the expression or code in its argument at runtime as a separate Perl program..."
> >>
> >>Does this mean that another interpreter is fired up to run the code in the eval?  This is a bit 
> >>worrying as the resources on the box are pretty minimal.  Is there a better way of trapping the 
> >>errors returned from the DBI that I am unaware of?
> > 
> > 
> > What I do is:
> <snip>
> 
> Thanks for that, I will give it a go.  Do you know if eval() does in fact start up another 
> interpreter when it is called?  Just so I know for future scripts.

Depends what you mean by 'start'.
The code will need to be parsed as part of execution, but that should not need the creation of a new
process (which is much more expensive that just throwing something at the parser occasionally).

There is not a lot of documentation as to how this works or the implications (uless you want
to roll your sleeves up & look at the code). Some of my programs do this sort of thing a lot:
	$var = 'fred';
	...
	${$var} = 42;

That does seem quite slow - unfortunately.

-- 
Alain Williams

#include <std_disclaimer.h>


-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug