Re^19: Try::Tiny and -E (False Negative)

As I already said, both need to be patched. I don't see a way how use feature could warn about a later use Try::Tiny (... well except of a general solution°)

And I prefer to see the warning at the line where the use appears, not the one with conflicting 'try {}'.

In general any module exporting subs that conflict with potential built-ins should check at import time.

The needed code to check the hint-hash should be refactored from feature.pm into a separate module.

footnote

°) In theory one could write an INC-hook which wraps around each use and require and checks the namespaces and hint-hashes for conflicts.

Like this no modules need to be patched.

Not sure if this is not an overkill tho.

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

see Wikisyntax for the Monastery}

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

Replies are listed 'Best First'.
Re^20: Try::Tiny and -E (False Negative) by ikegami (Patriarch) on Jan 08, 2026 at 16:33 UTC
If you can patch feature.pm, you can patch the feature itself. Both are Perl. No need to patch Try::Tiny to add a warning to Perl. And I prefer to see the warning at the line where the use appears Then we're back to false negatives and false positives. This subthread was discussing how to avoid those.	[reply]
Re^21: Try::Tiny and -E (False Negative) by LanX (Saint) on Jan 08, 2026 at 21:55 UTC
There are no false negatives if you patch both modules, and your example of false positives is not plausible. There is still a conflict, no falsehood there. You just amended the code later to avoid a real error in a sub-scope. The outer scope is still vulnerable for misinterpretation. And if the outer scope was never meant to use Try::Tiny::try() why even import it there? I gave a similar example of redefining a sub, which is written in a way that no real error happens. And it will nonetheless emit a warning. Now by your definition it's a false positive. By my logic the warning is in both cases economically justified, because it will only happen in very unusual or willfully constructed cases, make the author think about his dangerous design and can be trivially "solved" by disabling the warning. There are tons of examples of applications of `no warnings 'redefine'` in the monastery and I doubt anyone ever seriously called those cases "false positives". Anyway we are at Re:21 now, I think my point is clear by now ... :-) Cheers Rolf _{(addicted to the Perl Programming Language :) see Wikisyntax for the Monastery}	[reply] [d/l]