Re^17: Try::Tiny and -E (False Positive)

> You mean less simplified?

No I meant more plausible.

Perl is so flexible that you can most likely create false positives for every warning.

Doesn't mean they appear frequently enough for not being tolerable or solvable.

Here a similar example where redefine is causing a "false positive"

use strict;
use warnings;
use feature "say";
#no warnings 'redefine';
sub tst {1} 
BEGIN { $a = \&tst }
sub tst {2}
BEGIN { $b = \&tst }              
say &$a;
say &$b;
[download]

perl false_postive_redefine.pl
Subroutine tst redefined at false_postive_redefine.pl line 7.
1
2
[download]

And here a solution to your example.

Just move the use Try::Tiny into the scope where it belongs. This makes the code also far clearer.

use feature "try";
use constant CHECK_HINTHASH => 0;
sub check_hinthash {warn "feature_try = ".$^H{feature_try} if CHECK_HI
+NTHASH}
#...

BEGIN { check_hinthash() }    # feature enabled

{
  no feature qw( try );
  BEGIN { check_hinthash() }    # feature disabled
  use Try::Tiny qw( try catch );
   
  try { ... };   
}

BEGIN { check_hinthash() }    # feature enabled

# try { ... };  <-- would fail
[download]

Cheers Rolf
_{(addicted to the Perl Programming Language :)

see Wikisyntax for the Monastery}

Comment on Re^17: Try::Tiny and -E (False Positive) Select or Download Code

Replies are listed 'Best First'.
Re^18: Try::Tiny and -E (False Positive) by ikegami (Patriarch) on Jan 08, 2026 at 16:35 UTC
> You mean less simplified? No I meant more plausible. That just means obfuscated here, which I politely called less simplified.	[reply]
Re^19: Try::Tiny and -E (False Positive) by LanX (Saint) on Jan 09, 2026 at 00:27 UTC
There is no plausible reason why this shouldn't cause a warning. Either it's involuntary bad design, and the author should be warned. (The right design is to only `use Try::Tiny` in the desired scope) Or the author does exactly know why he's doing this and can easily disable the warning. Considering that many projects are maintained by multiple authors, who often just C&P "working" code from former authors, this warning might be a good idea... > which I politely called less simplified. I politely called this "constructed" The only probable "false positive" I see in reporting conflicts is by using `feature "try"` in a class/package also defining a method `->try()` which is never called as a function. But this warning would never be reported in my concept, because `use feature` normally happens long before subs are declared. Again: Pathological exceptions to that style imply that the author should actively disable the warning. Cheers Rolf _{(addicted to the Perl Programming Language :) see Wikisyntax for the Monastery}	[reply] [d/l] [select]