G'day Hilary,
chromatic wrote:
(Want a heuristic which finds *actual* bugs in almost every module ever
written? Check the use of eval and subsequent $@ testing, or the use of
ref(), or SUPER::whatever(), for example.)
Hilary Holz requested:
Could you expand a bit, please (or provide pointers to an existing reference
or references)?
There's a discussion of eval/$@ happening (or finishing) on p5p right now.
It starts at [1].
It doesn't list all the eval/$@ pitfalls, but the ones that immediately
bring to mind include:
* Exception-handling code that directly or indirectly uses eval,
which then results in $@ being cleared. Copying $@
before doing anything with it is recommended.
* Related to that, any code that uses an eval without
localizing $@ can clobber a value in $@ that the caller
may have cared about.
* Anything that does localizing $@ can result in problems
trying to re-throw errors unless extra care is taken.
See [2].
* Objects can use eval inside their DESTROY blocks, which
can result in $@ being cleared when the eval exits,
even though an exception occured!
* Signals can clobber [EMAIL PROTECTED] See [3].
The recommended way to use eval looks like this:
eval {
# code that may die goes here...
1;
} or do {
my $err = $@;
print "Oh no! Something went wrong\n";
# Use $err to hopefully figure out what happened.
};
Eval returns false if it captures an exception, or the last value of the
block (in our case, 1) if successful. We then hope that $@ is still around
by the time we get to it.
I'm not exactly sure which pitfalls chromatic is alluding to with regards to
ref() and SUPER:: .
All the best,
Paul
[1] http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2008-06/msg00507.html
[2] http://rt.perl.org/rt3/Ticket/Display.html?id=29696
[3] http://rt.perl.org/rt3//Ticket/Display.html?id=47928
--
Paul Fenwick <[EMAIL PROTECTED]> | http://perltraining.com.au/
Director of Training | Ph: +61 3 9354 6001
Perl Training Australia | Fax: +61 3 9354 2681
