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]

From:
Felipe Gasper
Date:
June 9, 2022 02:27
Subject:
Re: $@ alternative WAS Re: Core exception types [was: Re: Pre-RFC: Improve “wide character” warnings]
Message ID:
4A1D5C2B-1EC1-4D52-9469-40F0F4ED639E@felipegasper.com


> On Jun 8, 2022, at 22:19, Karen Etheridge <perl@froods.org> wrote:
> 
> 
> On Wed, Jun 8, 2022 at 12:56 PM Dan Book <grinnz@gmail.com> wrote:
>>> Whenever $@ is populated, the relevant logic would check to see if the active feature set dictates putting the object or the string into $@.
>> 
>> This is exactly the problem. The lexical feature would have an effect on the exact problematic code we are discussing (which is by the way not "esoteric" in any useful sense of the word, we simply cannot break it), which is not in the scope of the feature.
> 
> If I'm following correctly, we want the *caller* of the exception-throwing code to decide whether it wants an error string or an error object. Therefore, make $@ into a dualvar-like construct that holds both pieces of information, and use the context of the caller to decide which form is used in an expression containing $@.

Exactly.

This could even be as simple as: if native try/catch is used, throw the object; otherwise, the string. (Since try/catch remains experimental its behaviour can still change.) Code that uses eval would have no means to get the object.

-F


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