Prev: FAQ 7.27 How can I comment out a large block of Perl code?
Next: FAQ 6.7 How can I make "\w" match national character sets?
From: Ben Morrow on 2 May 2010 19:48 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 3 May 2010 01:42
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 |