On Wed, 30 Aug 2017 06:44:51 -0700, alexander.kiryu...@gmail.com wrote: > 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.
