Kripa Sundar wrote:
> I saw a friend using an eval() where it was unnecessary.
> (The code he used was "eval $string", where the value of
> $string was known at compile-time.)
[...]
> * delayed error detection and impact on correctness:
> If there is a typo in the system() string that you constructed,
> such as a missing quote mark or extra open parenthesis, the problem
> will not be detected until all the preceding execution is complete.
> If the preceding code did something permanent (i.e, something that
> has life beyond the process itself) we will be left with a messy
> situation. e.g.: if the preceding code renamed a file to a
> temporary location, with the expectation that it will be restored
> at the end of the script, then the incomplete run (caused by the
> delayed error detection) can cause problems that are hard to fix.
You seem to be blending the concepts of eval and system.
The delayed syntax checking problem can be mitigated by using the block
variation of eval (eval {}).
Your comments about doing "something that has life beyond the process
itself" and "incomplete run" seem a bit muddled and not consistent with
how eval behaves. Yes, as another poster pointed out, if you don't check
$@ after an eval, an error (compilation or otherwise) can go unnoticed,
if that's what you mean.
> * efficiency:
> It causes the perl interpreter to be launched at run-time.
eval certainly isn't efficient, but it isn't quite as bad as you imply.
It's not as if a new process is forked and executed. As I understand it,
the penalty is in having to compile the eval'ed code, but that
compilation is done by the same interpreter process running your script.
I'm not sure how much overhead the block form of eval imposes, if the
eval'ed code doesn't vary at run time.
> * security:
> ...eval() opens us up for security problems caused by human error.
The security implications will be highly dependent on where your $string
comes from that is being eval'ed. If it is built programmatically from
constants within the code or using validated (untained) data, then it
isn't much less secure than many other Perl constructs.
> Of course, eval() is a valuable tool, with many valid uses.
It (more specifically the block form) seems to get used a lot these days
as a way to as a way to catch exceptions - a Perl equivalent for
try/catch. (Of course there is a module on CPAN that implements
try/catch, I assume using eval.)
-Tom
_______________________________________________
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
