Bug #79138 for Perl-Critic: RequireArgUnpacking confused by @_ in finally{}

Yup, that's a bug. Thanks for bringing it to our attention.

Coupla thoughts: First, it seems to me that the use of finally() is not directly related to what perlcritic is doing. My evidence: the script #!/usr/bin/perl use strict; use warnings; use Try::Tiny; sub my_method { my ( $self ) = @_; # try { # sub_which_could_fail(); # } # catch { # deal_with_error(); # } # finally { print 'No error' unless (@_); # }; return; } (with everything commented out _but_ the offending line, and in particular the whole try/catch/finally thing) produces exactly the same error. Second, the line number reported is, strictly speaking, wrong; it ought to be line 16, since the @_ in the finally() block (in the original example) has nothing to do with the @_ in the subroutine at large. I have not looked at programming this change, though my knee-jerk is that I'm not smart enough to do it -- at least, not without building into Perl::Critic an intimate knowledge of how Try::Tiny works. I may be wrong, though, since setting short_subroutine_statements = 3 suppresses the error. Third, it appears to me that Damien does not address uses of @_ to discover the number of arguments. It also seems to me that this is what the ticket is really about. The policy actually has some code to allow checking the number of arguments, though at this point the only things allowed are '@_ == $something', '$something == @_', '@_ != $something', and '$something != @_'. Maybe it should have more?