develooper Front page | perl.perl5.porters | Postings from June 2022

Re: Core exception types [was: Re: Pre-RFC: Improve“wide character” warnings]

Thread Previous | Thread Next
Paul "LeoNerd" Evans
June 8, 2022 16:25
Re: Core exception types [was: Re: Pre-RFC: Improve“wide character” warnings]
Message ID:
On Wed, 8 Jun 2022 18:17:44 +0200
Ovid <> wrote:

> Paul, can you elaborate on the breakage? If try {...} catches
> non-blessed errors and upgrades them to a Exception::Legacy object
> which stringifies (or numifies) on demand (feature guarded, of
> course), why does this break stuff? Maybe I missed it in the thread,
> and I'm sure there will be code which still breaks, but it seems the
> majority of legacy code would work with this (especially since the
> majority of legacy code doesn't use your try/catch).

Ah, now that's an interesting thought. Combined with:

On Wed, 8 Jun 2022 16:06:47 +0200
Alexander Hartmaier <> wrote:

> 3) use a new variable that holds the exception object and populate $@
> with its string representation?

This might actually be a thing.

We can't change the existing behaviour of $@, but we *could* create
some other variable, say, ${^EXCEPTION}, that would receive these new
objects, and say that actually the catch var uses that instead:

  try { ... }
  catch($e) {
    if($e isa X::Perl::ENOENT) { ... }

These objects could then have whatever new interface we decided.

If the user is still using "legacy" eval-and-$@ then they'll receive a
stringified version of the object in that case, so as to not break
legacy behaviour.

I could imagine that being a thing.

Paul "LeoNerd" Evans      |  |

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About