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

unhandled Failure detected in DESTROY on require #6480

Closed
p6rt opened this issue Aug 30, 2017 · 5 comments
Closed

unhandled Failure detected in DESTROY on require #6480

p6rt opened this issue Aug 30, 2017 · 5 comments

Comments

@p6rt
Copy link

p6rt commented Aug 30, 2017

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

Searchable as RT131996$

@p6rt
Copy link
Author

p6rt commented Aug 30, 2017

From alexander.kiryuhin@gmail.com

This one is tough.

http://colabti.org/irclogger/irclogger_log/perl6?date=2017-08-30#l469 - the
original conversation with Zoffix.

croservices/cro@11aac95
- 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

--
--
Alexander.

@p6rt
Copy link
Author

p6rt commented Sep 1, 2017

From @skids

On Wed, 30 Aug 2017 06​:44​:51 -0700, alexander.kiryuhin@​gmail.com wrote​:

This one is tough.

http://colabti.org/irclogger/irclogger_log/perl6?date=2017-08-30#l469
- the
original conversation with Zoffix.

croservices/cro@11aac95
- 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.

@p6rt
Copy link
Author

p6rt commented Sep 1, 2017

The RT System itself - Status changed from 'new' to 'open'

@p6rt
Copy link
Author

p6rt commented Dec 23, 2017

From @zoffixznet

I reproduced this in our own test suite. Reported on rakudo/rakudo#1332
(gonna close this ticket in favour of that Issue)

It works, but occasionally throws​:

Note that it's a warning, not an exception.
You can work-around this bug with `andthen` operator​: `(require SomethingOrOther) andthen Nil;`

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.

Can't quite picture a scenario where you'd want to create a Failure,
but not indicate a failure. If there's no failure, don't make a Failure,
and if the user wishes to ignore it, then can easily disarm it by evaluating
it in boolean context or in anything that'd call .defined on it.

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.

It often means they made a mistake in their code and they're program is
progressing despite encountering an error​:

  sub load-customer-orders {
  Failure.new​: "Customer canceled all the orders"
  }

  my $n-molds = load-customer-orders.elems;
  say "Making $n-molds molds for the widgets!";
  say "I sure hope the number is accurate. These are expensive!";

  for ^100 { $ = eager -1000..rand }

  # OUTPUT​:
  # 2017.11.50 zoffix@​VirtualBox~$ perl6 /tmp/z.p6
  # Making 1 molds for the widgets!!
  # I sure hope the number is accurate. These are expensive!
  # 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​:
  # Customer canceled all the orders
  # in block <unit> at /tmp/z.p6 line 5
  #
  # 2017.11.50 zoffix@​VirtualBox~$

@p6rt
Copy link
Author

p6rt commented Dec 23, 2017

@zoffixznet - Status changed from 'open' to 'resolved'

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