When the business logic is tied to "at time of object destruction", there is no practical way to put the code into "delete". See tye's reply for a very good round-up of the DESTROY-based "guard pattern"
Re^6: Throw from within a DESTROY block
Replies are listed 'Best First'.
Oh, I thought you were saying you could use guard logic to fix your program.
I was confused because what you are saying is a complete non-sequitor. I didn't say you should always move code out of destructors. I'm well aware of the value of a destructor (and of tye's solution).
You ask for cheats to solve your particular case, but every time I provide one, you say it won't work in all circumstances. I'll say it again even though you said it was incendiary to say so, but that's not how Perl works.
If a particular solution doesn't work for your, say why, but don't say it can never work.
Quoting from http://www.perlmonks.org/?node_id=924499:
But the wonderful value of DESTROY is that every c'tor (constructor) that succeeds will always be followed by its paired d'tor, which makes it a very valuable tool for the sane handling of tons of things (all manner of resource allocation but also other things that should always be done in pairs, like transactions, reference counting, etc.). And handling tons of things means that you need to be able to deal with that handling going wrong or failing.