in reply to Try::Tiny and -E

-E activates all features and try/catch is one of them.

The parser is most likely expecting the catch{} part after try{}

I think Try::Tiny should attempt to warn you or die.

You might want to open a ticket.

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

(As of 2025-12-26 12:59 GMT, not sure when this post will get thru...)

Replies are listed 'Best First'.
Re^2: Try::Tiny and -E
by 1nickt (Canon) on Dec 26, 2025 at 13:54 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.

        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.