On Sun, Jul 2, 2017 at 4:02 PM, Eric Brine <ikeg...@adaelis.com> wrote:

> `eval BLOCK` is very different `eval EXPR`.
>
> The latter involves the need to generate Perl code, and ask the related
> risks. That's not the case for the former, which is the right tool for the
> job here.
>

​The above is quite right.

Unpacking it a little ...​

​1. Scalar Eval​

The evil eval that all the old docs warn against is classic original
interpretative eval:
   eval "some string with $evil $unclean $bits"; # EVIL eval string
which may look like
   eval $scalar;  # came from who knows
(which may stringify any non-string $scalar at need)
and in either case it calls the compiler at run time, each time.

That way lies reliability and security madness.

(It still has its uses, rarely, when building certain kinds of DWIM magic
... but mortals should use a well-tested module that encapsulates that
magic.)

2. Block Eval

More recently added to Perl but so far back any perl not supporting it is
very very obsolete is :
  eval { statements; expressions; }  # Good eval BLOCK
which compiles once with the program.
This doesn't totally relieve your from untainting user input - they can
still feed you "XLII" instead of  42 - but is much less dangerous wrto
"Little Bobby Tables" injections.

3. Try-Catch

​The other thing besides eval {oops} used to catch errors in modern perl
code is to use a module that provides a try-catch statement extension,
something like -
     try{ statements; that; might; die or throw; } catch { error handler;
}  ​

This is more than just simple syntactic sugar around eval { block; }
because it makes the error handling much less ugly.
(Especially if throwing object-oriented errors in ISA hierarchy.)

​There are many competing try-catch modules.
     https://metacpan.org/search?q=try%2Dcatch​
​
( My usual rule of thumb is try a ::Simple​ or ::Tiny variant first :-)
But i'm not sure which if any is particularly better or worse adapted to
catching DateTime erroneous input errors.  Maybe someone else has been
there. )


-- 
Bill Ricker
bill.n1...@gmail.com
https://www.linkedin.com/in/n1vux

Reply via email to