Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using wrong number of arguments in a start { ... } block in a map block doesn't always raise the correct exception #3734

Closed
p6rt opened this issue Mar 16, 2015 · 5 comments

Comments

@p6rt
Copy link

p6rt commented Mar 16, 2015

Migrated from rt.perl.org#124073 (status was 'resolved')

Searchable as RT124073$

@p6rt
Copy link
Author

p6rt commented Mar 16, 2015

From @hoelzro

The example program (attached) invokes &worker with an incorrect number of parameters, but sometimes (19/100) the program locks up, and other times (52/100) throws the wrong exception (Type check failed in binding exception; expected 'Any' but got 'Mu'). 29/100 times, the correct exception (Unhandled exception​: Too few positionals passed; expected 2 arguments but got 1) is thrown.

I'm testing this on the JVM right now, but as can be expected, it's taking a lot longer.

@p6rt
Copy link
Author

p6rt commented Mar 16, 2015

From @hoelzro

use v6;

sub worker(Any $a, Int $b) {}

my $value = Any;

my @​workers = (^2).map​: {
  start { worker($value) }
};

await @​workers;

@p6rt
Copy link
Author

p6rt commented Mar 16, 2015

From @hoelzro

This does *not* occur on the JVM.

@p6rt
Copy link
Author

p6rt commented Jan 18, 2016

From @hoelzro

On 2015-03-15 18​:05​:24, rob@​hoelz.ro wrote​:

The example program (attached) invokes &worker with an incorrect
number of parameters, but sometimes (19/100) the program locks up, and
other times (52/100) throws the wrong exception (Type check failed in
binding exception; expected 'Any' but got 'Mu'). 29/100 times, the
correct exception (Unhandled exception​: Too few positionals passed;
expected 2 arguments but got 1) is thrown.

I'm testing this on the JVM right now, but as can be expected, it's
taking a lot longer.

This appears to be fixed!

@p6rt
Copy link
Author

p6rt commented Jan 18, 2016

@hoelzro - Status changed from 'new' to 'resolved'

@p6rt p6rt closed this as completed Jan 18, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant