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

Opened https://rt.cpan.org/Ticket/Display.html?id=172434.


The way forward always starts with a minimal test.

Replies are listed 'Best First'.
Re^3: Try::Tiny and -E
by LanX (Saint) on Dec 26, 2025 at 14:49 UTC
    Thank you.

    In hindsight it might be that Try::Tiny is complied before the -E takes effect.

    Not sure about the compilation order here. °

    In that case only something like an INIT {} block could catch the conflict.

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

    °) redefining a built-in should fail...

      > In hindsight it might be that Try::Tiny is complied before the -E takes effect.

      Indeed. In this special case it's actually too early to check from within Try::Tiny.

      I checked with feature::feature_enabled("try"); and feature::features_enabled($LEVEL); for various levels.

      But the case of perl -E'use Try::Tiny; try {1/0}' could be checked, and from what I see is Try::Tiny not attempting to catch this.

      So haarg's reply to the ticket is not fully correct.

      On another note: I'm wondering, shouldn't Perl warn if a built-in is clashing with an (exported) sub???

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

      EDIT

      Ticket updated.

        Given the difficulties for a module to test whether one of its routines could clash with a built-in, the solution is easy:
        1. State clearly in the docs that as from Perl 5.40 there may be a clash with a built-in;
        2. Have Try::Tiny check it is running under Perl 5.40 or later and issue a warning about a possible clash.
        And leave it to the programmer to do what is necessary. No need to add unnecessary complexity and fragility to a Tiny::* module.

        CountZero

        A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

        My blog: Imperial Deltronics

      It doesn't matter when the Try::Tiny is compiled. Features have a lexical scope, so it's all about the context in which the try keyword is compiled. And while that is possible to check that context to see if the feature is enabled, it's out of reach of Try::Tiny since I believe it's intentionally a pure-Perl module.

        you are wrong on both accounts.

        > It doesn't matter when the Try::Tiny is compiled.

        I've explicitly tested this with feature::feature_enabled() and order definitely matters.

        It's basically the difference between:

        use feature "try"; use Try::Tiny;

        vs

        use Try::Tiny; # no chance (well see footnote°) use feature "try";

        And that's because lexical scope starts right at the point of declaration.

        > it's out of reach of Try::Tiny since I believe it's intentionally a pure-Perl module.

        It's very much possible with a pure-Perl module like I said. The _enabled routines in feature are basically checking the hinthash %^H returned by caller for the needed level.

        And the hint-key is called "feature_try"

        A slight complication is that feature introduced "try" before it provided the *_enabled checks. IOW one needs to copy the hint-hash lookup logic for older Perl versions.

        Footnotes

        °) the wrong order could be fixed by using an INIT {} block doing the check after all compilations are completed, but I question the wisdom of such a fragile construct. Too many edge cases.¹

        ¹) Turns out that neither INIT,CHECK or UNITCHECK can see the hint anymore.

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

        update

        little demo v5.38

        perl -E'BEGIN{say join "\n",feature::features_enabled()}' bareword_filehandles bitwise current_sub evalbytes fc indirect isa module_true multidimensional postderef_qq say signatures state unicode_eval unicode_strings