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