Front page | perl.perl5.porters |
Postings from June 2022
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.
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Thread Previous
|
Thread Next