Re: How many different ways can Perl code fail?

FTFD:

In both forms, the value returned is the value of the last expression evaluated inside the mini-program; a return statement may be also used, just as with subroutines. The expression providing the return value is evaluated in void, scalar, or list context, depending on the context of the eval itself. See "wantarray" for more on how the evaluation context can be determined.
If there is a syntax error or runtime error, or a die statement is executed, an undefined value is returned by eval, and $@ is set to the error message. If there was no error, $@ is guaranteed to be a null string. Beware that using eval neither silences perl from printing warnings to STDERR, nor does it stuff the text of warning messages into $@ . To do either of those, you have to use the $SIG{__WARN__} facility, or turn off warnings inside the BLOCK or EXPR using no warnings 'all' .

1. Check for eval returning undef + $@ != null.
2. setup $SIG{__WARN__} to inform you when a warning's going to print.

Comment on Re: How many different ways can Perl code fail?

Replies are listed 'Best First'.
Re^2: How many different ways can Perl code fail? by ikegami (Patriarch) on Jan 13, 2009 at 21:30 UTC
Check for eval returning undef + $@ != null. Checking `$@` is a bit unreliable. Better: `if (!eval { ...; 1 }) { ...error handler... }` [download] Or if you need the return value: `my $rv; if (!eval { $rv = ...; 1 }) { ...error handler... }` [download]	[reply] [d/l] [select]
Re^3: How many different ways can Perl code fail? by diotalevi (Canon) on Jan 14, 2009 at 09:10 UTC
Even better, use tye's Devel::EvalError. ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊	[reply]
Re^4: How many different ways can Perl code fail? by sgt (Deacon) on Jan 14, 2009 at 21:39 UTC
Guard seems interesting too. I haven't tested it but it's on my Perl todo list. Obviously not the same "niche" of application, but could be complementary (at least). cheers --stephan	[reply]
Re^3: How many different ways can Perl code fail? by wol (Hermit) on Jan 14, 2009 at 17:45 UTC
Why is using $@ a bit unreliable? Update: Just found that the answer to this is covered by the documentation of Devel::EvalError. A quick read seems to suggest that the issue can only arise if there's a DESTROY method which uses eval (however indirectly) and doesn't localise $@. You'll have to decide whether that would be a problem for you... -- use JAPH; print JAPH::asString();	[reply]
Re^4: How many different ways can Perl code fail? by ikegami (Patriarch) on Jan 14, 2009 at 18:00 UTC
You'll have to decide whether that would be a problem for you... Not really. It's not like it's harder to handle the problem. I'd say it's even cleaner. `eval { ... }; if ($@) { ... }` [download] vs `eval { ...; 1 } or ...;` [download] and `my $x = eval { ... }; if ($@) { ... }` [download] vs `my ($x) = eval { ... } or ...;` [download]	[reply] [d/l] [select]


Syntactic Confectionery Delight
	PerlMonks