I was going to mention the possibility of using a $SIG{__DIE__} that calls exit, but it doesn't work. The signal is triggered before the object is destroyed, so a second attempt to destroy the object occurs during global destruction. | [reply]
[d/l]
[select] |
This can be trivially fixed by closing over an $already_fired flag of some sort to neutralize the DESTROY for a specific object. However I am not interested in an exit() - I want a real trappable exception that will happen during runtime calls to DESTROY (I am not interested in the global destruction case, and can always work around it)
| [reply] |
If I move the die() out of the DESTROY, this becomes a non-question don't you think? :) The whole point is to figure out why perl thinks we are cleaning up (even though we are in the middle of runtime), and how to convince it otherwise. | [reply] |
If I move the die() out of the DESTROY, this becomes a non-question don't you think?
If you don't, then your question is a non-question. ("How do you make Perl not act like Perl?")
The whole point is to figure out why perl thinks we are cleaning up (even though we are in the middle of runtime),
It is cleaning up an object, and you're wrong in thinking Perl think it's in the global destruction phase.
$ perl -wE'
DESTROY { die "foo" }
{ bless({}) }
'
(in cleanup) foo at -e line 2.
$ perl -wE'
DESTROY { die "foo" }
our $o = bless({});
'
(in cleanup) foo at -e line 2 during global destruction.
| [reply]
[d/l] |
| [reply] |
