Skip to content
Permalink
Browse files

Make IO::Path.dir throw rather than fail

In general, if something is returing an Iterable, we throw rather than fail
to prevent exactly the problem that R#2650 describes.  Is spectest clean, so
we weren't too strict about this anyway.
  • Loading branch information...
lizmat committed Jan 27, 2019
1 parent 71a19c6 commit 38f4b7b4383c976ac95f9d812a832638a047ee07
Showing with 1 addition and 2 deletions.
  1. +1 −2 src/core/IO/Path.pm6
@@ -526,8 +526,7 @@ my class IO::Path is Cool does IO {
proto method dir(|) {*} # make it possible to augment with multies from modulespace
multi method dir(IO::Path:D: Mu :$test = $*SPEC.curupdir) {
CATCH { default {
fail X::IO::Dir.new(
:path($.absolute), :os-error(.Str) );
X::IO::Dir.new(:path($.absolute), :os-error(.Str)).throw
} }

my str $dir-sep = $!SPEC.dir-sep;

5 comments on commit 38f4b7b

@salortiz

This comment has been minimized.

Copy link
Contributor

replied Mar 7, 2019

I hop isn't to late to be against.
I used to wrote

with '/some/dir'.IO.dir -> @content {
...
} else { 
   .fail
}

In general I think that every throw prevents the handling with with reducing its usefulness.

@AlexDaniel

This comment has been minimized.

Copy link
Member

replied Mar 7, 2019

@salortiz interesting… can you file a ticket, please? At the very least we probably want to grep through the ecosystem for lines like that.

In general I think that every throw prevents the handling with with reducing its usefulness.

But I don't think it prevents much. Just add a try (like with try '/some/dir'.IO.dir …)

@salortiz

This comment has been minimized.

Copy link
Contributor

replied Mar 8, 2019

@AlexDaniel, using with try hides the Failure in the else block, please compare:

with try +"a" { ... } else { say $_ ~~ Failure } # False, $_ is Nil

with

 with  +"a" { ... } else { say $_ ~~ Failure }  # True

While a Failure can be handled cleanly with with, //, orelse, etc. or opted-out by the fatal pragma or, in this case, a simple type constraint; throw should be handled with try and $! or with a CATCH block, both polluting the lexical scope.

Try to rewrite, with the current status the elegant:

with 'optional'.IO.dir // 'existent'.IO.dir -> @content { … }

It is a matter of flexibility and choices to the user. In my opinion, Perl6's Exception/Failure model is an important differentiator, despite not being very widespread nor well documented.

A simple my Str @foo = ... would have sufficed to the original #2650 reporter.

I'm thinking in fill a ticket in spec to encourage the discussion in search of 'best-practices' in this matter.

Any thoughts @lizmat?

@Leont

This comment has been minimized.

Copy link
Contributor

replied Mar 13, 2019

Any reason why this wouldn't suffice?

CATCH { .fail }
@salortiz

This comment has been minimized.

Copy link
Contributor

replied Mar 14, 2019

As a CATCH block modifies the semantic of the lexical scope around it, I use only when I needs centralized handling for, potentially many unrelated, Exceptions.

This is all about different paradigmatic positions.

My main stance in this 'thrown Exception' vs 'return Failure' is that the former, as a one-way road, forces the user to use the CATCH paradigm, the latter allows others. TMTOWTDI

Please sign in to comment.
You can’t perform that action at this time.