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

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

Thread Previous | Thread Next
From:
Martijn Lievaart
Date:
June 8, 2022 19:55
Subject:
Re: $@ alternative WAS Re: Core exception types [was: Re: Pre-RFC: Improve “wide character” warnings]
Message ID:
1696b081-7b52-093b-346a-3b3aac0c307d@rtij.nl
Op 08-06-2022 om 19:28 schreef Felipe Gasper:
>> 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.


I don't think these cases are so esoteric. But hiding behind a feature 
flag means users of the old behaviour can just specifically turn this 
off when they want do all the other goodness from use 
v6.<some-high-version>, but don't want to break risking their 
user-defined-object based exception code. So I agree, this is very doable.


HTH,

M4



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