Continuing in the face of exceptions, and what's the negation of // ?

[Austin Hastings]

I retract my opposition to "err". After coding this:

        try
        {
            try { path = f.getCanonicalPath(); }
            catch (Exception e) { path = f.getAbsolutePath(); }
        }
        catch (Exception e) { path = f.toString(); }

I am now a convert. To the extent that we are going to throw exceptions,
there needs to be a quick way of huffmanizing the scaffolding.

IIRC, "use fatal" decides between an exception being thrown and an
"undef but ..." value being returned.

IMO, it's important to coerce code into the same behavior: If a sub that
I call tries to throw an exception, that needs to be converted into
undef-but-whatever, too.

One problem, of course, is drawing the line: «|die| creates a "normal"
exception»[A4] so how, if at all, can a library coder force an abort? I
suspect exit() is the only way -- there's always some guy wanting to
override everything.

So the "err" operator, or whatever, has to suppress fatal, call, check,
return:

  sub infix:<err> (Code &lhs, Code &rhs)
  {
    no fatal;
    &lhs;
   CATCH {  &rhs;  }
  }


Producing:

  my $path = $f.getCanonicalPath()
    err $f.getAbsolutePath()
    err $f.toString();

But using "no fatal" at the top of your code reduces this to plain old //:

  no fatal;
  my $path = $f.getCanonicalPath()
    // $f.getAbsolutePath()
    // $f.toString();

I wonder what '\\' means?

Is it the negation of //? So that:

  my $x = $hash<$key> \\ die "Error: hash<$key> already defined!"

Or can we continue the breaktyping theme and grab it for fatal-suppression?

Alternatively, of course, there's always /// or //! -- probably one of
these is best, extending the theme of the "if undef" to include "if
undef (and exception is very undef!)".

At any rate, count me in for suppressing errors inline -- also for
tarring and feathering the guy who put that kind of crap in the Java
standard library.

=Austin