From: Ben Morrow on

Quoth "C.DeRykus" <derykus(a)gmail.com>:
>
> Or you may want to wrap the call in an eval {} for more
> control...
>
> my $parse = eval { Spreadsheet::ParseExcel->new(); };
> die "error: ... $@" if $@;

It's always safer to use the return value of eval, rather than testing
$@:

my $parse = eval { Spreadsheet::ParseExcel->new }
or die "error: ... $@";

If a signal comes in between the 'eval' and the 'if', or if S::PE->new
leaves something on the stack with a destructor, and that code clears
$@, the first construction will miss the error. The second will still
see the wrong value for $@, but that's better than not catching the
error at all.

Ben

From: C.DeRykus on
On May 2, 4:48 pm, Ben Morrow <b...(a)morrow.me.uk> wrote:
> Quoth "C.DeRykus" <dery...(a)gmail.com>:
>
>
>
> > Or you may want to wrap the call in an eval {} for more
> > control...
>
> >   my $parse = eval { Spreadsheet::ParseExcel->new(); };
> >   die "error: ...  $@" if $@;
>
> It's always safer to use the return value of eval, rather than testing
> $@:
>
>     my $parse = eval { Spreadsheet::ParseExcel->new }
>         or die "error: ... $@";
>
> If a signal comes in between the 'eval' and the 'if', or if S::PE->new
> leaves something on the stack with a destructor, and that code clears
> $@, the first construction will miss the error. The second will still
> see the wrong value for $@, but that's better than not catching the
> error at all.

Yes, that's true although, even if the error's not caught,
the problem will be exposed quickly when a method's called
on the undefined $parse object. But, getting the error much
earlier at the scene of the crime is certainly preferable
even with the remote possibility of seeing a bogus $@.

--
Charles DeRykus