Front page | perl.perl5.porters |
Postings from June 2021
On Wed, 23 Jun 2021 at 08:47, Nicholas Clark <nick@ccl4.org> wrote:
> On Wed, Jun 23, 2021 at 07:01:01AM +0200, Branislav ZahradnÃk wrote:
> > Accepting contribution via github PR:
> >
> https://github.com/happy-barney/perl-poc/blob/perl-rfcs/RFC-exception-catalogue.md
>
> Technically this might no longer be my call to make
> (although I may be delegated some work - I'm assuming that the new PSC
> doesn't
> claim a monopoly on enthusiasm either)
>
> but
>
> 1) We specifically asked for elevator pitches first, not draft RFCs
> 2) This draft RFC doesn't fit the template. Sections such as
> "Backwards Compatibility" are important, and in the template for that
> reason
> 3) There are actually good ideas in here that can be done independently
> This message can be split into several elevator pitches.
>
ok, so next time no RFC in subject but EPI (EPO? :-))
>
> ONE:
>
> > ## Express intention with symbol
> > ## Deduplicate error literals
>
> This is an internal refactoring, and doesn't need an RFC
> (A refactoring by definition shouldn't change user behaviour)
>
> I think that this sort of cleanup would be a really good idea. It's rather
> large though - do you have an idea how to do it incrementally?
>
Incrementally ? yes, it's possible
Put in here as strongly related (we can even assign numbers internally)
>
>
> TWO:
>
> > ## Match errors
> >
> > Test may look like (although `~~` may be more appropriate)
> > ```
> > if ($@ == ${^PerlX_00400}) {
> > }
> > if ($@ == ${^PerlX_Function_Not_Implemented}) {
> > }
> > ```
>
> This is a user visible change. This itself belongs in an RFC.
> Clearly it's dependant on the first refactoring.
>
> Using `==` implies that $@ becomes (at least) a dual var, exposing a
> numeric value as well as the original string.
>
> This *seems* like a reasonable idea, but it's not obvious how it it then
> interacts with user-generated exceptions, and objects as exceptions.
>
>
I agree, `==` may not be proper operator (I used "may look" for that
therefore I mentioned
that smart match will be much more appropriate.Or abusing `isa` to detect
it's behaviour by rhs
> > Grey area: raising exceptions added after implementing this rfc
>
> You're completely missing user generated exceptions.
>
Yes and no.
User generated exceptions will never match system exceptions and doesn't
need
follow "error number" pattern.
User generated exceptions should be instances (so `isa` can be used in
catch conditions).
We can also provide "my $errno = define user exception".
On other hand user should be able to write "die ${ ^PerlX_00400 }"
>
> > ## Exceptions as an object
> >
> > Create internal package literals to allow exception match via `isa`
> >
> > Usable by `catch`
> >
> > ```
> > if ($@ isa CORE::X::X00400::)
> > if ($@ isa CORE::X::Function::Not::Found::)
> > ```
>
> Exceptions can already be objects:
>
>
This proposal is about internal exceptions, those witch currently acts as
strings.
Idea behind this is to pass this tests:
ok ! blessed ($@);
ok $@ isa CORE::X::X00400::;
>
> I don't think that this plan really works as-is. It seems to completely
> miss
> that existing code can already generate exceptions that will not be in the
> "official" catalogue, *and* it seems to ignore exception objects.
>
This proposal covers only internal exceptions (I'm sorry if it was not
clear)
>
> Nicholas Clark
>
Thread Previous
|
Thread Next