[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