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

Re: RFC - core exception catalogue

Thread Previous | Thread Next
Branislav Zahradník
June 23, 2021 16:29
Re: RFC - core exception catalogue
Message ID:
On Wed, 23 Jun 2021 at 17:31, Nicholas Clark <> wrote:

> 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.

Oh, that's what I'm actually doing, stripping parts of much larger document
.. :-)

But I got what you want to say.

> 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.

So this answers my question I had when you came with RFC idea (maybe it was
answered then and I missed that) - yes,  there will be milestones. And that
answers markdown vs pod - github flavored markdown has task list.

> > 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)

depends on point of view. if you can get exception without using require /
use, than
it should behave like this.

OK, so technically what you are saying, that exception catalogue should not
be singleton
but available for any other module to use their own numbering scheme. Eg
eg: ${ ^PerlX_Foo_Bar_00400 }

That's doable, I can imagine implementation. Did I understand it correctly?

> > 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.

Oracle SQL - standard numbers and range of number to be usable by modules
(without allocation).

> >
> > ok ! blessed ($@);
> > ok $@ isa CORE::X::X00400::;
> You can't do that with the current internals.

I'm aware of that, that's why it is mentioned as "related work" (or

> 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.

I'd split question into to:
1. do you have symbol table attached?
2. are you object?

It can be done with using virtual function table pattern.
Disadvantage is, according my current knowledge it implies refactoring of

> It's similar to wanting to be able to overload references so that
>    defined $obj
> returns false - objects are always going to be defined.

not quite,
you are asking wrong question which only by a chance returns you answer you
you can overload boolean conversion of object and use proper question: "!!

> Or wanting to call methods on undef
> * there is only one value that is undefined
> * it's not an object, and can't be

It's not object but can have attached namespace.

> Nicholas Clark

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About