[Gllug] perl eval()

will will at hellacool.co.uk
Thu Jun 20 16:55:48 UTC 2002


Jason Clifford wrote:
> On Thu, 20 Jun 2002, will wrote:
> 
> 
>>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():
>>
>>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?
> 
> 
> perldoc -f eval 
> 
> should tell you more.
> 
> I use code like so:
> 
> $sql = "..."
> eval ($dbh->do($sql));
> if ($@)	# $@ is the return from eval if anything went wrong
>   {
>   # do whatever...
>   }
> 
> It's nice and simple and it works well.

Yeah, the code is pretty simple, but when perl 'Evaluates the expression or code in its argument at 
runtime as a separate Perl program' to interpret the eval (quote from perl in a nutshell, oreilly), 
does this mean that perl (about 5 Mb?)interpreter is loaded into memory again doubling the number of 
interpreters running and therefore the amount of memory used (even if temporarily)?  If this is the 
case I would need to avoid this method of checking for errors as the box can barely cope with 1 perl 
process as it is.

Will.




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




More information about the GLLUG mailing list