On Sat, 30 Sep 2017 13:47:22 -0700, [email protected] wrote:
> So I included at least one discussion in the ticket that was utterly
> pointless and left unread. At this point I'm just going to assume only
> half-exposing the underlying mechanism is considered a feature and I need
> to use a different language when it's not.
You mean the part about exposing different stat() error conditions?
A `Failure` wraps a typed exception, which you can get at by calling the
`.exception` method on it:
my $is-file = do given $path.f -> $result {
with $result.?exception {
when X::IO::DoesNotExist { ... }
when ... { ... }
when ... { ... }
default { ... }
}
$result.so
}
(...or by letting it throw and then using a CATCH block.)
Exceptions also have type-specific attributes which can hold further details to
differentiate similar but different error conditions.
If file tests should be made to expose more fine-grained error states (probably
a good idea), they can use those two mechanisms without the need to change
anything about Failure or add new syntax.
PS: At the end of the day, "only half-exposing the underlying mechanism" of
low-level operating-system APIs is to be expected though, for a high-level
language that wants to be cross-platform and user-friendly. Getting full access
to specific operating-system APIs is what third-party modules such as [1] are
for. Thankfully, Perl 6's NativeCall interface makes them relatively easy to
write.
---
[1] https://github.com/cspencer/perl6-posix
