FAQ
The recent 5.13 patches try to improve the reliability of exceptions
handling, but I think there are still serious deficiencies.

Perl's reference counting makes RAII a fairly common pattern, which
means that destructors are treated as a potentially meaningful part of
the program.

For example, IO::AtomicFile renames the file in its close method, and
its DESTROY method calls close automatically. The close method takes a
flag, and when true it dies on errors. This flag is set in DESTROY.

The attached test demonstrates the a possible scenario whereby a
legitimate error is borged; the eval returns true as if no failure had
happened (if the eval is removed, no error is printed at all, and the
exit code is 0).

A more concise example:

% perl -e 'sub DESTROY { warn "going to die"; die "foo" }; my $x =
bless {}' && echo success
going to die at -e line 1.
success
%

The only difference 5.13 makes is that if we add eval { undef $x } to
that script, older perls will have some evidence of an error in $@,
whereas 5.13 removes this pollution.

I personally think that 'die' in DESTROY should make an eval { } fail
(including setting $@) and should kill the program outside of one.

However, when DESTROY is being called because an error occured (as the
eval { } stack frames are being unwound), it should not overwrite the
"main" error, which obviously is one of the goals of the recent
changes.

That said, those quelched errors in DESTROY are potentially still
important. The best solution I can come up with is what I proposed
last time, i.e. pushing to a new @@ variable.

Search Discussions

  • Zefram at Jul 8, 2010 at 9:44 am

    Yuval Kogman wrote:
    For example, IO::AtomicFile renames the file in its close method, and
    its DESTROY method calls close automatically. The close method takes a
    flag, and when true it dies on errors. This flag is set in DESTROY.
    There certainly is a problem with dying in destructors, and there
    always was. My changes don't substantially affect that position.
    Stuff I'm intending to do outside the core will provide a solution,
    which modules such as IO::AtomicFile might eventually want to adopt.

    -zefram

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl5-porters @
categoriesperl
postedJul 7, '10 at 9:41p
activeJul 8, '10 at 9:44a
posts2
users2
websiteperl.org

2 users in discussion

Yuval Kogman: 1 post Zefram: 1 post

People

Translate

site design / logo © 2022 Grokbase