[Gllug] perl eval()

[will]

Alain Williams wrote:
> 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 same as when you run a standalone perl process.

> 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).

Good, this is what I don;t want to happen, the box is weak.

> 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).

Not that it would do me much good.  There is a good reason I program perl :-)

Will.



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