eval {
    Module::That::Dies::die_here();
    1;
} or do {
    warn "Error from Module::That::Dies:\n$@\n";
};
[download]

bartender1382: I just wanted to highlight that eval { ...; 1 } or do { ... } is indeed the correct pattern to use, instead of the unfortunately still common eval ...; if ($@) - see Bug in eval in pre-5.14 and my reply Re: Bug in eval in pre-5.28. In fact, this use of eval is very similar in function to Try::Tiny. The latter just has a few small advantages as described in its documentation, while the eval solution has the advantage that it is pure Perl built-in (Update: Try::Tiny is pure Perl too, but not a core module).

Yes, eval definitely works!

Quick followup:

Do I need the 1; ? It works with and without it, just wanted to make sure it might not be needed for something internal, or was it there for an example?

eval {
    Module::That::Dies::die_here();
    1;
} or do {
    warn "Error from Module::That::Dies:\n$@\n";
};
[download]

Do I need the 1; ?

Generally, yes, you should include it. The reason is that eval returns undef on failure, which is what the or do { ... } is intended to react to. However, the or would also be triggered if the eval block were to return any other false value, such as 0 or the empty string. For example, the following incorrectly prints "Error from Module::That::Dies:". So unless you can be absolutely sure that the eval block always returns a true value, you should include the 1 (or any other true value) as the last statement of the block.

sub Module::That::Dies::die_here { return 0 }
eval {
    Module::That::Dies::die_here();
    #1;
} or do {
    warn "Error from Module::That::Dies:\n$@\n";
};
[download]

Update: I tend to write it like the following, since the 1 on a line by itsself can look out of place and might be accidentally deleted:

eval {
    ...
;1 } or do { # catch
    ...
}
[download]

I, too, use the eval { ...; 1; };. I'm literally just writing unit tests with eval right now, so I thought I'd share how I often write them:

my $missing_opt_code_succeeded = eval {
    $tesla->option_codes('NON_EXIST');
    1;
};

is
    $missing_opt_code_succeeded,
    undef,
    "If an option code doesn't exist, we croak ok";

like 
    $@, 
    qr/does not exist/, 
    "...and error message is sane";
[download]

"Do I need the 1;?"

++ Good question.

I would always include it. If you think other maintainers may not understand its importance, add a comment like:

eval {
    ...;
    1; # IMPORTANT! Do not remove. See: https://www.perlmonks.org/?nod
+e_id=11143055
} or do {
    ...;
};
[download]

Even in situations when the last statement in the eval block evaluates to 1, or some other TRUE value, I would include it:

eval {
    ...;
    $x = 1;
    1;
} ...;
[download]

Otherwise, if someone removes the '$x = 1;' line, or changes the value, but does not know, or forgets, to add the '1;' statement, the 'eval {...} or do {...};' construct may be broken.

— Ken

I think it depends; for this module I would do this since it returns the reference if successful.

local $@;
my $book = eval {
  Spreadsheet::Read->new($file);
};
[download]

or

local $@;
my $book;
my $ok = eval {
  $book = Spreadsheet::Read->new($file);
  1;
};
[download]

The second example seems like "more work" to handle the error and is a lot messier. So in this case adding the "1" is superfulous since the called sub actually returns something (or doesn't).

A case where I'd use 1; with an or undef thrown in:

local $@;
my $ok = eval {
  doSomethingButDontWantReturnValButCouldDie() or undef;
  1;
};
[download]

I think ultimately, the answer is like I stated above, it depends - on what you're doing and expecting; and how you tend to check for/handle exceptions.

I've also done this; but usually it's a game time decision for me.

local $@;
my $ok = eval {
  doSomethingButDontWantReturnValButCouldDie();
  1;
} or undef;
[download]

I'd like to add as a separate comment, while the use if the 1; is "it depends"; I would absolutely always localize $@ as close in scope to the eval {} as make sense; usually right before it (unless it's already been done in the same scope and if there are a series of eval{}s that have already been successfully executed.

local $@;
my $ok = eval {
  doSomethingButDontWantReturnValButCouldDie() or undef;
  1;
};
[download]