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

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

Thread Previous | Thread Next
From:
Felipe Gasper
Date:
June 8, 2022 17:28
Subject:
$@ alternative WAS Re: Core exception types [was: Re: Pre-RFC: Improve “wide character” warnings]
Message ID:
4C3363DC-8CF9-4F8D-9283-83820089AF7A@felipegasper.com

> On Jun 8, 2022, at 12:25, Paul LeoNerd Evans <leonerd@leonerd.org.uk> wrote:
> 
> 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:

An interesting idea. I guess all of the available punctuation variables are taken, though?

It would be a shame if, to access the new-hotness, one had to work harder to type ${^EXCEPTION} as opposed to just $@.

As Ovid indicated, just making $@ a stringifying object would prevent breakage except in esoteric cases. If it’s behind a feature flag then that’ll make those cases all the rarer. So I, at least, don’t see why there seems to be such resistance.

It’s already hard for neophytes to juggle $@, $!, $?, and $^E. Adding a 5th “error variable” seems likely to worsen that.

As an alternative: what if, under `use feature 'errorobject'`, $@ were the object, but without the feature it’d be the string? So the feature would only change how eval populates $@.

-F

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About