Front page | perl.perl5.porters |
Postings from June 2022
> On Jun 8, 2022, at 15:56, Dan Book <grinnz@gmail.com> wrote:
>
> On Wed, Jun 8, 2022 at 3:45 PM Felipe Gasper <felipe@felipegasper.com> wrote:
>
> > On Jun 8, 2022, at 13:38, Dan Book <grinnz@gmail.com> wrote:
> >
> > As was shown in the example, you don't actually use the proposed variable yourself in try/catch as it sets up a lexical variable for the scope of catch.
>
> That would certainly encourage adoption of try/catch.
>
> > 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 $@.
> >
> > This is not possible, because it is not populated lexically.
>
> I don’t think that matters:
>
> -----
> {
> use feature 'errorobject';
>
> eval { 9 / 0 };
> }
>
> say blessed $@; # prints something
>
> {
> no feature 'errorobject';
>
> eval { 9 / 0};
> }
>
> say blessed $@; # prints nothing
> -----
>
> 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.
The lexical feature would only affect code that enables it specifically, though.
It’s the same situation as signatures: the only things that would see $@ as an object are code paths that specifically ask for that behaviour.
-FG
Thread Previous
|
Thread Next