in reply to Re^10: Try::Tiny and -E
in thread Try::Tiny and -E

Yes, but I have no idea how this contradicts what I already said.

If use Try::Tiny sees "feature_try" in the callers hint hash it can (at least) warn.°

And if use feature "try" sees "try", "catch" or "finally" in the callers stash it can warn.

Elaborate edge cases for false positives and false negatives please.

What I suggested are well defined compile-time actions.

Cheers Rolf
(addicted to the Perl Programming Language :)
see Wikisyntax for the Monastery

°) IMHO it should die, but this is open to debate.

Replies are listed 'Best First'.
Re^12: Try::Tiny and -E
by ikegami (Patriarch) on Jan 02, 2026 at 09:36 UTC

    If use Try::Tiny sees "feature_try" in the callers hint hash it can (at least) warn.

    The issue, as mentioned repeatedly, is that it's impossible to check the hash at the correct time.

    Elaborate edge cases for false positives and false negatives please.

    What matters is whether the feature is enabled when the try call is compiled. You suggested calling at 3 or 4 other times. But that won't work. If you perform the check as these wrong times,

    • It can warn even there's no issue.

      This happens if the feature is enabled in the lexical scope being compiled when you perform your check, but it's not enabled for the lexical scope that contains the try call.

    • It can not warn when there is an issue.

      This happens if the feature isn't enabled in the lexical scope being compiled when you perform your check, but it is enabled for the lexical scope that contains the try call.

    Provide your check, and I'll provide a case that fails.

      > Provide your check, and I'll provide a case that fails.

      see feature*_enabled checks demonstrated in Re^5: Try::Tiny and -E and Re^7: Try::Tiny and -E

      Try::Tiny can check either inside import() or die/skip right at the beginning of the module.

      NB: you can provide a caller level to this routines.

      > If you perform the check as these wrong times,

      What should be the benefit of Try::Tiny exporting it's subs while feature-try is enabled?

      In theory you could no feature "try" later in a sub-scope to re-enable those exports, but that's a very convoluted edge-case.

      And I was mostly talking about "warning", warnings can be disabled if this convoluted edge-case is warranted.

      Looking forward to your counter-examples!

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      see Wikisyntax for the Monastery

        Try::Tiny can check either inside import() or die/skip right at the beginning of the module.

        False positive:

        use v5.40; use Try::Tiny qw( try catch ); ... { # Code that hasn't been converted to 5.40 yet, for example. no feature qw( try ); try { ... }; } ...

        False negative:

        use Try::Tiny qw( try catch ); ... { use feature qw( try ); try { ... } catch ( $e ) { ... } } ...

        What should be the benefit of Try::Tiny exporting it's subs while feature-try is enabled?

        I didn't say it shouldn't be done. I said it doesn't always work. To evaluate if it should be done or not, it's important to know when it won't work correctly.