I reproduced this in our own test suite. Reported on
https://github.com/rakudo/rakudo/issues/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~$
