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
unhandled Failure detected in DESTROY
on require
#6480
Comments
From alexander.kiryuhin@gmail.comThis one is tough. http://colabti.org/irclogger/irclogger_log/perl6?date=2017-08-30#l469 - the croservices/cro@11aac95
It works, but occasionally throws: ``` So there are basically two problems here: How to reproduce: Maybe not for the first time, but this occurs maybe for every 3 times, or Anything, especially golfing is appreciated. Or better name(especially
-- |
From @skidsOn Wed, 30 Aug 2017 06:44:51 -0700, alexander.kiryuhin@gmail.com wrote:
I think you would find that if you guaranteed the program to run long and Personally I have always disagreed with the idea that we should warn when So really I'd kick this over to [SPEC], but that is just my personal preference. On a practical level, as a workaround, the originating module would have to |
The RT System itself - Status changed from 'new' to 'open' |
From @zoffixznetI reproduced this in our own test suite. Reported on rakudo/rakudo#1332
Note that it's a warning, not an exception.
Can't quite picture a scenario where you'd want to create a Failure,
It often means they made a mistake in their code and they're program is sub load-customer-orders { my $n-molds = load-customer-orders.elems; for ^100 { $ = eager -1000..rand } # OUTPUT: |
@zoffixznet - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#131996 (status was 'resolved')
Searchable as RT131996$
The text was updated successfully, but these errors were encountered: