That was my next thought about attacking the problem. I’d prefer being able to enable my desired behaviour with some sort of pragma somewhere and then not have to do anything special in the affected code, though. If I have to do any extra work at all (and if it’s just remembering to instantiate a particular IO class instead of just calling open), I’d rather stick to doing dumb and simple extra work than adding insufficiently magic complexity to the code.

Makeshifts last the longest.

The following triggers IO::Handle::DESTROY. It does not trigger IO::File::DESTROY even though this is a file handle.

use IO::Handle; # or IO::File
*IO::Handle::DESTROY { print "here\n" }
{
    open my $fh, '<', 'a-file' or die;
}
[download]

⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

That seems to be the only reliable approach. You don’t even need to load IO::Handle. However, I can’t actually get it to complain:

use strict;

sub IO::Handle::DESTROY {
    my $self = shift;
    warn +(caller 0)[3]."($self)\n";
    close $self or die "$!\n";
}

{ if( open my $fh, ">", "/dev/full" ) { print { $fh } 1 } }

warn "Terminating\n";
__END__
IO::Handle::DESTROY(IO::Handle=IO(0x8130c0c))
Terminating
[download]

The error does occur: if I change the die to a warn, I see the warning. But while die aborts execution (statements after it will not run), I can’t make it throw an exception. The conditions from Carping in DESTROY, which was mentioned in another subthread, do not apply either.

Makeshifts last the longest.