failures

sub calc { return 1 if rand > 0.5; fail "Postponed" }
my @b;
for ^4 { @b.push(calc) }
@b.push(2);
@b.push(Promise.new.break);
@b.push(3);
for @b { $_ ?? say "Result: $_" !! say "Retrying..."; }



19:33 < notviki> TimToady: should IO methods throw or fail?
19:33 < notviki> like spurt, open, chdir
19:34  * geekosaur draws distinctions there
19:34 < geekosaur> spurt and open are file operations, fail is reasonable
19:35 < geekosaur> process-level state changes (chdir) should be a harder failure mode
19:35 < notviki> and pipe, slurp, indir, tmpdir, homedir, rename, copy, symlink, and link
19:35 < geekosaur> ...but I think chdir is the only such that gets exposed; most of them would be highly OS specific
19:35 < notviki> all of the listed currently throw... though for some reason move() appears to fail
19:36 < notviki> or rather throw on anything, but fail on X::IO::Copy|X::IO::Unlink :/
19:37 < notviki> hm...
19:38 < notviki> It's even worse: many subs throw, but methods fail :S
19:38 < moritz> can we just always throw exceptions please?
19:38 < moritz> fail was meant to make concurrent code cheaper
19:38 < notviki> moritz: for all IO routines?
19:38 < moritz> but start blocks catch exceptions anyway, and rethrow them when accessing Promise.result
19:39 < moritz> notviki: all IO routines, but I mean really everywhere
19:39 < notviki> :o
19:39 < moritz> I think fail() was a mistake, and it's time we admitted it
19:39 < notviki> I'd find that really annoying to write try {} everywhere
19:40 < moritz> my $fh = try open $filename
19:40 < moritz> not much worse than my $fh = open $filename
19:40 < moritz> and you check $fh anyway later on to make sure it doesn't throw when you use it
19:42 < moritz> I see none of the benefits that fail() was supposed to give us anywhere in real-world code
19:43 < notviki> What were the benefits?
19:44 < moritz> making sure some massively parallel computations didn't die just because a single sub-computation failed
19:44 < moritz> and not burdening parallel code with error handling
19:44 < notviki> And that's it?
19:44 < moritz> (which we still need, because we can't know that stuff only fails and never will die)
19:45 < moritz> I'm not aware of other supposed benefits
19:45 < notviki> I always seen it as an easier way to throw that doesn't encoumber you with all the try {} ugliness
19:46 < notviki> Like from-json here throws, so I have that try block and because } ends statement I have
     to place // in an weird place: https://github.com/zoffixznet/perl6-buggable/blob/master/lib/Buggable/Plugin/Eco.pm6#L40
19:46 < notviki> And here $!r6.stats fails() and it's just an `or` statement: 
     https://github.com/zoffixznet/na/blob/master/lib/NA/Plugin/Release.pm6#L15
19:49 < notviki> ugggh... so github now made it possible for submitters to request a specific person to review a PR....
19:49 < notviki> ... and now I'm asked to review a couple for no good reason? :/
19:50 < TimToady> moritz: we've gone over this many time, it also allows you to treat failure with logic instead of
     putting try blocks everywhere
19:51 < TimToady> and if you fail in sink context, it throws immediately anyway, just like you want
19:53 < notviki> TimToady: any idea for what to do for IO stuff? Fail or throw? We're now kinda half-way in between
     and I wanna know how to fix it.
19:54 < TimToady> fail was mostly invented for IO stuff in the first place
19:54 < TimToady> errand &
19:55 < notviki> alright
20:00 < japhb> Also, with/orwith/without make more sense in a world with Failure in it.
20:09 < moritz> TimToady: so have you observed benefits from fail() in real-world code?
20:10 < notviki> I have. No need to stick try {} all over the place.
20:11 < moritz> notviki: so do you actually do error reporting for each thing that could 
                fail?
20:11 < moritz> or error handling, for that matter
20:12 < notviki> sometimes I let it just sink and explode.
20:13 < notviki> I mean, it's really close to just exceptions *without typing try {}* all 
                 over teh place
20:13 < notviki> or sometimes I do // "some value"
20:13 < notviki> instead of try {} // "some value"
20:24 < japhb> I tend to use // a LOT.  One of my favorite operators.
20:25 < japhb> In fact I use it so often, I have to force myself to use || when I really do mean Truthiness and not
     just Definedness