in reply to Carping in DESTROY.

Storable's documentation states that store() returns undef on failure, and that failure usually indicates an IO error. Thus, you should be checking its return value just as you would check the return value of other IO calls.

store $self, DATA_FILE or die "Couldn't store object.\n";

[download]

Dave

Replies are listed 'Best First'.
Re^2: Carping in DESTROY.
by diotalevi (Canon) on Oct 24, 2006 at 17:34 UTC

    I don't know where this is documented but die() in DESTROY isn't thrown on my 5.8.7.

    sub A::DESTROY { die 'ok' }
my $obj = bless [], 'A';
$obj = ''; # no exception occurs
print "$@\n"; # "        (in cleanup) ok at - line 1."

    [download]

    ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

[reply]
[d/l]

      It does get thrown — anything after the die won't get executed — but it's intercepted by DESTROY's caller. 

      my $var = 1;
sub A::DESTROY { $var = 2; die 'ok'; $var = 3; }
my $obj = bless [], 'A';
$obj = ''; # no exception occurs
print "$var\n"; # 2
print "$@\n";   # "        (in cleanup) ok at - line 1."

      [download]

      This behaviour isn't new. Tested with 5.6.1

[reply]
[d/l]
[select]
        Actually, my eval try was in erorr. This is giving me what I want: 
        sub DESTROY {
    my $self = shift;
    eval { store $self, DATA_FILE };
    die $@ if $@;
}

        [download]
        I partially understand this. This is what Storable is doing: 
        ...
sub logcroak {
    Carp::croak(@_);
}
...
open(FILE, ">$file") || logcroak "can't create $file: $!";
...

        [download]
        I'm still a little confused why I have to capture the croak and then die, as opposed to letting it croak.
[reply]
[d/l]
[select]
Re^2: Carping in DESTROY.
by eff_i_g (Curate) on Oct 24, 2006 at 17:33 UTC
    davido,

    I tried die and eval; neither of them show an error. I'll prepare some example code...

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom