Kind of. The line commented out is meant to get access to the perl variable $! so that it can assign the error code and text into it (the else branch of the if statement), so that these will be available to the calling application.

If it successfully obtains access to $! and takes the else branch, then the sub returns to it's immediate caller (other XS routines within the module), where those subs would then return undef or whatever to the calling application. The calling application (ie. your code), can then decide whether the error is something that it can saftely ignore and continue or abort as fits the purpose of the application.

As it currently stands (on CPAN), any API error passed into ErrorHandler() is always fatal which is a nonsense. It's hard to guess why that would have been commented out or by whom--it looks like it was a quick check that got forgotten to me. Whatever, it should be corrected which means someone should raise a perlbug against it.

As a workaround, though not a particularly satisfactory one because it means you will effectively be ignoring all api errors, you can use an eval block to trap the croak some thing like this:

use File::Find;
use Win32::FileSecurity;

#determine the DACL mask for Full Access
my $fullmask = Win32::FileSecurity::MakeMask('FULL');

&find(\&wanted,"\\");

my %users;

## Note: use return not next from a subroutine
## with warnings enabled perl will remind you of this
sub wanted {
    # Win32::FileSecurity::Get does not like the paging file, skip it
    return if ($_ eq "pagefile.sys");
    return unless -f $_;

    ## Do the get in an eval block and return 1 if it succeeds.
    ## Otherwise ignore the problem and go onto the next file.
    return unless eval{ Win32::FileSecurity::Get($_, \%users); 1 }; 
    return unless defined $users{"Everyone"};
    return unless $users{"Everyone"} == $fullmask;
    print "$File::Find::name\n";
}
[download]