From @b2gills

There have been discussions about how to get to the
point that new Perl5 code can identify the type of
error without resorting to a string match of the error.

My proposal is for the internal errors/warnings to produce
an object that has been tied. In this way old code would
work the same as always, and new code can call tied on
the error to get better information.

  use warnings qw' FATAL all ';
    eval{ say my $x; }; # uninitialized warning

  # use foreach on Perls which lexicalize $_
  given( tied $@​ // $@​ ){
  when( not defined $_ ){ } # skip out of block

  when( :​:warnings​::uninitialized ){
  # works on new versions of Perl
  }
  when( /^Use of uninitialized value/ ){
  # works on 5.10 an above
  }
  default{ die $@​ } # rethrow uncaught error
  }

Now comes the heart of my idea, a construct which does
a lot of the stuff in the given block above.

  CATCH{
  ...
  }

Which is basically the same as

  if( defined $@​ ){
  given( tied $@​ // $@​ ){

  ...

  default{ die $@​ } # die should throw tied objects unchanged
  }
  undef $@​; # optional; signifies the error was caught
  }

Of course if you provide a `default` block it replaces the normal one.

  CATCH{
  ...

  default{ } # ignore otherwise uncaught errors
  }

If user code generates an error it can be handled by the same construct​:

  eval{
  [
  sub{User​::Defined​::Error->throw},
  sub{
  tie my $e, User​::Defined​::Error, 'user defined error';
  die $e
  },
  sub{die('user defined error')},
  ]->[rand(3)]->()
  }
  CATCH{
  when( :​:User​::Defined​::Error ){
  # catches first two errors
  }
  when( /^user defined error/ ){
  # catches third error
  }
  when( $@​ ~~ /^user defined error/ ){
  # could have caught the second two errors if they
  # weren't already handled
  }
  # default{ die $@​ } # just use the normal default block
  }

The reason I don't have blocks which contain a `CATCH` block
implicitly wrap the rest of the code with an `eval` block (or similar),
is that it could dramatically slow down normal blocks.
It should probably do that though if it can be implemented in a way
that doesn't slow them down by much.

There could also be a `try` block which surrounds the rest
of the code with an `eval` block ( if `CATCH` doesn't implicitly do so).
It could also make warnings fatal, similar to Perl6,
so that they can be caught by the `CATCH` block.

  try{
  ...; # some code which could generate an error
  CATCH{
  ...
  }
  };

becomes​:

  do{
  # optional Perl6-like extension of the idea
  use warnings FATAL => 'all';

  eval{
  ...; # some code which could generate an error
  };
  CATCH{
  ...
  }
  };

I'm not certain how it should deal with code in the same outer block
which comes after the `CATCH` block.
( In Perl6 a single `CATCH` block handles the entire block, and there
is only one allowed per block. )

At some later point the internals could be changed to
call a method on the tied object that gets printed to STDERR
instead of printing the stringified form.
Effectively it can do something like this​:

  exit 0 unless defined $@​;

  $_ = tied $@​ // $@​;
  if( blessed $_ ){
  if( my $meth = $_->can('localized') ){ # the localized message
  print STDERR $_->$meth;
  }elsif( my $meth = overload​::Method($_,q[""]) ){
  print STDERR $_->$meth;
  }else{
  print STDERR $@​;
  }
  } else {
  print STDERR $@​;
  }
  exit 1;

That way the error that gets printed to STDERR can change over time
with as few breakages as possible.
( Any tests which check the STDERR for specific messages would break though. )

With this design user code can get the same benefits without having
to register an id unlike other proposals.