Skip Menu |

This queue is for tickets about the Syntax-Keyword-Try CPAN distribution.

Report information
The Basics
Id: 125971
Status: open
Priority: 0/
Queue: Syntax-Keyword-Try

People
Owner: Nobody in particular
Requestors: khedin [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 0.09
Fixed in: (no value)



Subject: nested try block + return from inner + nonempty destructor = garbage in array
The following example may look a bit artificial, but it's actually shorthand for "a project with multiple levels of indirection using Moo[se]". WHEN try {} is nested, AND the outer block assigns an array to result of indirectly called inner block, AND the inner block is in scalar/void context, AND the inner block is left by a return statement, AND such return triggers a nonempty DESTROY block, THEN a $@ value is prepended to array for no apparent reason.
Subject: 201807-try.pl
#!/usr/bin/env perl =head1 DESCRIPTION Nested try block + return from the inner block + destructor called = garbage in array =cut use strictures 2; use Test::Most tests => 1; use Syntax::Keyword::Try; eq_or_diff [outer()], [ 1, 123 ], "No extra data in return"; sub outer { my @result; try { @result = (1, scalar inner()); # scalar or void context is mandatory 1; # or catch will be triggered } catch { die "Something terrible happened: $@"; }; return @result; } sub inner { my $canary = Canary->new; # is this line is commented, nothing happens try { return 123; } catch { die "Something terrible happened: $@"; } } package Canary; sub new { bless {}, shift; }; sub DESTROY { my $x; # Destructor MUST be nonempty $@ = "oops"; # Assigning to $@ is optional };
On Tue Jul 31 05:12:01 2018, Dallaylaen wrote: Show quoted text
> The following example may look a bit artificial, but it's actually > shorthand for "a project with multiple levels of indirection using > Moo[se]". > > WHEN try {} is nested, AND the outer block assigns an array to result > of indirectly called inner block, AND the inner block is in > scalar/void context, AND the inner block is left by a return > statement, AND such return triggers a nonempty DESTROY block, THEN a > $@ value is prepended to array for no apparent reason.
I'm unable to reproduce the issue with the given script. It seems to pass for me, at least when I try it on 5.26 on my laptop. I wonder if it might be perl-version dependent... -- Paul Evans
On Fri Aug 17 10:15:28 2018, PEVANS wrote: Show quoted text
> I wonder if it might be perl-version dependent...
Passes on each of perl 5.14.4 (usethreads) perl 5.16.3 perl 5.18.2 perl 5.20.3 perl 5.22.2 perl 5.24.0 perl 5.26.1 perl 5.28.0 -- Paul Evans
Hello, Show quoted text
> Passes on each of > > perl 5.14.4 (usethreads) > perl 5.16.3 > perl 5.18.2 > perl 5.20.3 > perl 5.22.2 > perl 5.24.0 > perl 5.26.1 > perl 5.28.0
It passes on my laptop's default perl 2.22 and on *some* of my brewed perls, too. I'll try to figure out the difference.