Front page | perl.perl5.porters |
Postings from June 2022
On 6/8/22 10:25, Paul "LeoNerd" Evans wrote:
> On Wed, 8 Jun 2022 18:17:44 +0200
> Ovid <curtis.poe@gmail.com> 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 <alex.hartmaier@gmail.com> 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.
>
+1
Thread Previous
|
Thread Next