Front page | perl.qa |
Postings from February 2007
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 $@. 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
Thread Previous
|
Thread Next