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 15:31
Subject:
Re: RFC - core exception catalogue
Message ID:
20210623153139.GS11066@etla.org
On Wed, Jun 23, 2021 at 11:24:36AM +0200, Branislav Zahradník wrote:
> 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? :-))
Not just this.
Please also start with the "elevator pitch", not the full RFC.
You're welcome to *link* to a larger document, but pitch the pitch to
the list.
I'm behind on doing the minutes from last Friday, but we explicitly
discussed this, and we unanimously agreed that it was important to start
with (*short*) elevator pitches, not large templated documents.
It's easy to swamp the list with documents that are too large for people
to read, and so there won't be fast useful responses. There's a 1:500
ratio between writing an e-mail to the list and reading it - it *is* of
net benefit to the list functioning to write less at first.
(So yes, technically the new PSC can change its mind, but that would need
not just Paul disagreeing with what I just wrote, but also having Neil and
Rik change their minds.)
This is my opinion (not the previous or current PSC's) but getting the idea
summarised down to the elevator pitch is important. If it's proving hard,
that could mean:
1) There's actually more than one idea. (so more than 1 pitch and RFC)
2) It's not the right part of a bigger plan to start with
3) The plan is too large for the RFC process to handle.
That last one also matters - the RFC process was intended for incremental
changes. Things that can get done easily within a release cycle, and things
that (mostly) stand alone.
If the changes don't make sense without so many other things changed too,
such that features would need to ship "next year" that aren't actually
used yet, then that's something that belongs as a bigger branch (or
branches) that get rebased, but don't get merged until there's something
for the end user.
> > > 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.
I'm not convinced that this is a good direction to go - building a system
where one set of errors are "first class" and the others not.
Do errors generated from XS code shipped in the core get system exceptions?
Perl code? You seem to be wanting to make a distinction between errors
based on where they come from, which prevents us adopting code from CPAN
(or putting it out onto CPAN)
> 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 }"
Does *any* other dynamic language use numbers to describe this?
A text based system, with a class hierarchy seems much easier to use,
without needing to memorise masses of "magic" numbers, or constantly look
them up.
> > > ## 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::;
You can't do that with the current internals.
What you show needs simultaneously to be (in reverse)
* an object (with a payload)
* that isn't an object
This isn't going to work.
It's similar to wanting to be able to overload references so that
defined $obj
returns false - objects are always going to be defined.
Or wanting to call methods on undef
* there is only one value that is undefined
* it's not an object, and can't be
Nicholas Clark
Thread Previous
|
Thread Next