Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

Re: How many different ways can Perl code fail?

by mikelieman (Pilgrim)
on Jan 13, 2009 at 21:26 UTC ( #736088=note: print w/replies, xml ) Need Help??


in reply to 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 (Pope) 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... }

    Or if you need the return value:

    my $rv; if (!eval { $rv = ...; 1 }) { ...error handler... }

        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
      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();

        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 ($@) { ... }

        vs

        eval { ...; 1 } or ...;

        and

        my $x = eval { ... }; if ($@) { ... }

        vs

        my ($x) = eval { ... } or ...;

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://736088]
help
Chatterbox?
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (8)
As of 2018-07-19 15:01 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    It has been suggested to rename Perl 6 in order to boost its marketing potential. Which name would you prefer?















    Results (411 votes). Check out past polls.

    Notices?