Hi Dave,
On 2 Feb 2007, at 12:30, David Golden wrote:
[snip]
There is a different case that needs to be considered. Module Fribble
uses an eval in it's DESTROY method without error and thus Foo's fatal
error in an eval vanishes.
[snip]
Good point.
Because Perl normally warns but doesn't die on exceptions in DESTROY,
I would agree that T::E also shouldn't care about such exceptions.
I agree.
Extending that argument, T::E also shouldn't introduce capabilities
that wouldn't exist for an ordinary programmer using eval {} on
similar code in production. Consider:
dies_ok{ my $foo = Foo->new; die "Fatal Error" };
lives_ok{ my $foo = Foo->new; die "Fatal Error" };
I think a good case should be made that *both* of these should fail if
a DESTROY block with an eval is swallowing up [EMAIL PROTECTED] A good
diagnostic
that describes this unexpected result would help programmers realize
that some strange action at a distance is happening.
not ok 1
# Code died, but appeared to live because $@ was reset
# unexpectedly by a DESTROY method called during cleanup
not ok 2
# Code died, but appeared to live because $@ was reset
# unexpectedly by a DESTROY method called during cleanup
I quite like this. The problem would then be managing folk who get
around these sorts of problems by the:
eval { something(); 1 } ? "lived" : "died"
convention....maybe have variants of the subroutines... hmmm...
Ta,
Adrian
