views:

43

answers:

3

I'm used to `... or die ".. failed... $!";.

I was surprised to find that in order to know if File::Path::remove_tree failed or not I must do something like this:

remove_tree( 'foo/bar', 'bar/rat', {error => \my $err} );
if (@$err) {
 die "error..."
}

Am I missing something? Is this really the way to go?

A lot of unneeded code for me...

+3  A: 

remove_tree returns the number of files successfully deleted, so it needs another method of reporting an error than a return value. Bear in mind that a number of files may have been deleted before an error is encountered, so you can't rely on the returned value being 0 as indicating an error.

Whether this is the way to go for reporting errors is a matter of taste. From the docs themselves:

NOTE: The following error handling mechanism is considered experimental and is subject to change > pending feedback from users.

Dancrumb
in other words "If you have a better idea, I'm all ears!"
Ether
A: 

I remove one path at a time then check if it is still there afterward:

 foreach my $path ( @paths ) {
      my $rc = remove_tree( $path, { ... } );
      die ... if -e $path;
      }

As Dancrumb said, you can't trust the return value.

brian d foy
+1 Yeah, I know the return value is irrelevant here. I just wondered if that's common to failure testing to be so "demanding".
David B
When I'm dealing with the system and it matters, this is what I do. It's not that demanding.
brian d foy
A: 

The docs say that it raises exceptions:

If make_path or remove_tree encounter an error, a diagnostic message will be printed to STDERR via carp (for non-fatal errors), or via croak (for fatal errors).

That enabled us to use standard exception handling at least for the errors marked fatal.

use Try::Tiny;
try {
    … remove_tree …
} catch {
    warn "remove_tree failed: $_";
};

The warnings can be fatalised somehow, too, but I can't of anything decent right now except aliasing File::Path::_carp to File::Path::_croak.

daxim