in reply to Re: Try::Tiny complaining catch must be block or sub {} (not reference constructor)
in thread Try::Tiny complaining catch must be block or sub {} (not reference constructor)

Thanks monks!

False alarm. I needed to address the experimental push by casting my reference to array w/ @{}. It's in a different code block from try / catch block so I assumed the errors were unrelated (and they are) but fixing the one addresses the try / catch "issue".

Experimental push on scalar is now forbidden at [mymodule] line 474, n +ear "$asset;" Type of arg 1 to Try::Tiny::catch must be block or sub {} (not referen +ce constructor) at [mymodule] line 680, near "};" Type of arg 1 to Try::Tiny::try must be block or sub {} (not reference + constructor) at [mymodule] line 680, near "};"

I created short code sample below that illustrates the behavior in action (w/ the fix). Still not at all clear to me how the one (experimental push issue) affects the other, but I'm unblocked from making progress. Any thoughts?

use strict; use warnings; use 5.006; use Try::Tiny; my @array = (); my $array_ref = \@array; push $array_ref, 'test'; # bugbug #push @{$array_ref}, 'test'; # <== change prev line to be like this test(); sub test { try { my $a = 1/0; } catch { print 'awww, snap!'; }; 1; } 1; __END__

Replies are listed 'Best First'.
Re^3: Try::Tiny complaining catch must be block or sub {} (not reference constructor)
by haukex (Archbishop) on Jan 07, 2019 at 14:36 UTC
    Still not at all clear to me how the one (experimental push issue) affects the other, but I'm unblocked from making progress. Any thoughts?

    I don't know for sure, but I'd suspect that the earlier error caused the parser to get confused about the rest of the program, that kind of thing happens often - one syntax error can leave the parser in a bad state, and while it may try to parse the rest of the program to report as many other errors as it can, it obviously got it wrong in this case. That's why short yet complete examples like the one you showed (thank you for that) are always incredibly useful, since if we'd known there were other errors in addition to the one you stated in the root node, the fix would have probably become obvious faster.

      Thanks again. I kinda figured the same (cascading effect of one error leading to another) but wanted to draw attention to it just in case -- esp. since this wasn't a syntactical error like a missing curly brace.