I was surprised to find that a DESTROY handler called when an object goes out of scope changes the exit status of the child process it's running in, even if that child exits with exit(exit_code).

This code:

package Foo;
use strict;
use warnings;
sub new {
    bless {}, shift;
}
sub DESTROY {
    warn "$$: destroy";
    system("waaaah");
}

package main;
use strict;
use warnings;
use POSIX ":sys_wait_h";

my $foo = Foo->new();

my $pid = fork();

die "fork failed" if !defined $pid;

if( $pid ) {
    # parent
    print "$$: parent\n";
} else {
    # child
    print "$$: child\n";
    # system("waaaah");
    exit 5;
}

my $reaped = waitpid($pid, 0);

my $child_exit_status = POSIX::WEXITSTATUS($?);

print "pid=$reaped status: $child_exit_status\n";
[download]

shows

pid=4778 status: 255

although the child exits with exit(5). So the failing system() call in the DESTROY method of the object that goes out of scope overrides the explicitly set exit() value?

(If you comment out the system() call in the DESTROY handler and uncomment the one in the child code you'll get the expected exit code 5).

Surprised?