develooper Front page | perl.perl5.porters | Postings from June 2021

Re: RFC - core exception catalogue

Thread Previous | Thread Next
From:
Branislav Zahradník
Date:
June 23, 2021 09:24
Subject:
Re: RFC - core exception catalogue
Message ID:
CAB=rbOnrLi9e0z-hfY6SvmHTEe7wTZPUfrae3ZY4yYmfsEttXA@mail.gmail.com
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


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