Skip Menu |
Report information
Id: 131996
Status: open
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: alexander.kiryuhin [at] gmail.com
Cc:
AdminCc:

Severity: (no value)
Tag: (no value)
Platform: (no value)
Patch Status: (no value)
VM: (no value)



Subject: `unhandled Failure detected in DESTROY` on `require`
From: Alexander Kiryuhin <alexander.kiryuhin [...] gmail.com>
Date: Wed, 30 Aug 2017 16:44:40 +0300
To: rakudobug [...] perl.org
Download (untitled) / with headers
text/plain 1.8k
This one is tough.


>require ::{$_};
line.

It works, but occasionally throws:

```
WARNING: unhandled Failure detected in DESTROY. If you meant to ignore it, you can mark it as handled by calling .Bool, .so, .not, or .defined methods. The Failure was:
No such symbol 'Cro::Tools::Template::ZeroMQWorkerService'
  in sub get-available-templates at /home/koto/Work/cro/cro/lib/Cro/Tools/TemplateLocator.pm6 (Cro::Tools::TemplateLocator) line 31
  in sub MAIN at /home/koto/Work/cro/cro/lib/Cro/Tools/CLI.pm6 (Cro::Tools::CLI) line 115
  in block <unit> at bin/cro line 1
```

So there are basically two problems here:
1)This package really exists with a correct name and everything(see below). Yet it throws.
2)Even if it isn't, it should throw, then be caught by catch block, etc.

How to reproduce:
1) zef install cro # To get all the dependencies.
3) cd cro
4) git reset --hard fb251c594c3ed04cd9a16c1b045f4380abb40549 # To reset a workaround
5) perl6 -Ilib bin/cro stub http my-test-service ./my-test-service :secure; # A couple of times, it's good to write it like
6) (opt) perl6 -Ilib bin/cro stub http my-test-service ./my-test-service :secure; rm -rf my_test_service/ # to remove the directory immediately for easier multi-try.

Maybe not for the first time, but this occurs maybe for every 3 times, or 10 times in a row - based on your luck.

Anything, especially golfing is appreciated. Or better name(especially this).

>perl6 --version
>This is Rakudo version 2017.08-28-gd8958fc37 built on MoarVM version 2017.08.1-19-g151a2563

--
--
 Alexander.
Download (untitled) / with headers
text/plain 2.9k
On Wed, 30 Aug 2017 06:44:51 -0700, alexander.kiryuhin@gmail.com wrote: Show quoted text
> This one is tough. > > http://colabti.org/irclogger/irclogger_log/perl6?date=2017-08-30#l469 > - the > original conversation with Zoffix. > > https://github.com/croservices/cro/commit/11aac95b9ef94a1db43521a72ebd323f6281c202 > - this commit introduces TemplateLoader that has
> > require ::{$_};
> line. > > It works, but occasionally throws: > > ``` > WARNING: unhandled Failure detected in DESTROY. If you meant to ignore > it, > you can mark it as handled by calling .Bool, .so, .not, or .defined > methods. The Failure was: > No such symbol 'Cro::Tools::Template::ZeroMQWorkerService' > in sub get-available-templates at > /home/koto/Work/cro/cro/lib/Cro/Tools/TemplateLocator.pm6 > (Cro::Tools::TemplateLocator) line 31 > in sub MAIN at /home/koto/Work/cro/cro/lib/Cro/Tools/CLI.pm6 > (Cro::Tools::CLI) line 115 > in block <unit> at bin/cro line 1 > ``` > > So there are basically two problems here: > 1)This package really exists with a correct name and everything(see > below). > Yet it throws. > 2)Even if it isn't, it should throw, then be caught by catch block, > etc. > > How to reproduce: > 1) zef install cro # To get all the dependencies. > 2) git clone https://github.com/croservices/cro.git > 3) cd cro > 4) git reset --hard fb251c594c3ed04cd9a16c1b045f4380abb40549 # To > reset a > workaround > 5) perl6 -Ilib bin/cro stub http my-test-service ./my-test-service > :secure; > # A couple of times, it's good to write it like > 6) (opt) perl6 -Ilib bin/cro stub http my-test-service ./my-test- > service > :secure; rm -rf my_test_service/ # to remove the directory immediately > for > easier multi-try. > > Maybe not for the first time, but this occurs maybe for every 3 times, > or > 10 times in a row - based on your luck. > > Anything, especially golfing is appreciated. Or better name(especially > this). >
> > perl6 --version > > This is Rakudo version 2017.08-28-gd8958fc37 built on MoarVM version
> 2017.08.1-19-g151a2563
I think you would find that if you guaranteed the program to run long and hard enough to reach a GC DESTROY it would happen 100% of the time. Also IIRC there's some flag to tell rakudo to always use the GC to clean up before process exit. Personally I have always disagreed with the idea that we should warn when Failures get thrown away and destroyed, as merely creating a Failure object does not mean a Failure has been experienced -- it just means you have a Failure you can throw at the user at an appropriate time. If the user never steps on the land-mine you planted, then that means they were not interested in using the part of your module that was unhappy, so no harm done. 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 stop preparing Failure objects before it finds a way to place them directly under the user's foot.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org