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

Re: RFC - core exception catalogue

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
June 23, 2021 06:47
Subject:
Re: RFC - core exception catalogue
Message ID:
20210623064723.GK11066@etla.org
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.

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?


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.

> ## Fine-tune / evolve exception text
> 
> Proposal allows changes of exception texts without breaking old codes.
> 
> Once feature (bundle) is enabled, its should be an error to match `$@`
> with regular expressions.
> 
> Due backward compatibility there should be two catalogues:
> - compatible (messages will not be modified)
> - evolvable (messages follows this proposal)
> 
> Grey area: raising exceptions added after implementing this rfc

You're completely missing user generated exceptions.

> ## 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:

$ perl -wE 'sub bark { say "woof" }; eval { die bless [] }; say "here"; $@->bark'
here
woof


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.

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