Re^2: How many different ways can Perl code fail?

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]

Comment on Re^2: How many different ways can Perl code fail? Select or Download Code

Replies are listed 'Best First'.
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]