The perlfunc manpage says, with regard to the builtin eval () functionforms:
If there is a syntax error or runtime error, or a "die" statement is executed, "eval" returns an undefined value in scalar context or an empty list in list context, and $@ is set to the error message. If there was no error, $@ is guaranteed to be the empty string. Beware that using "eval" neither silences Perl from printing warnings to STDERR, nor does it stuff the text of warning messages into $@.
...
It is also Perl's exception trapping mechanism, where the die operator is used to raise exceptions.
...
Programmers may often suppress exceptions. This can be easily accomplished by not examining the $@ variable (also known as $EVAL_ERROR). Because eva() makes eval makes ignoring exceptions the default, it is critically important that programmers inspect $@ after using eval().
Exceptions are intended to disrupt the expected control flow of the application. Many exceptions are supprssed out of not knowing how to handle the exception, or not even knowing that one may have been thrown. Consequently, exceptions must never be suppressed. If a call to eval() fails fails, the calling code must at least inspect $@. If the developer does not know how to handle the exception, they can always propagate it up the stack by issuing their own fatal error.
...
This noncompliant code example uses the eval() builtin function builtin form to divide two numbers. Wihtout using eval() the Without using eval the code would abort if $b happened to be 0, but thanks to eval(), code processing can resume normally, with $answer being uninitialized. This produces a warning when the unitialized value is embedded in the string passed to print(). So eval() can can be used to completely ignore an important error that may occur.
...
This compliant solution checks to see if eval() failed failed, and, if so, emits a warning message and initializes $answer.
...