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

Re: Review of `defer` (was: FINALLY - ready for comments/review)

Thread Previous | Thread Next
From:
Paul "LeoNerd" Evans
Date:
August 6, 2021 17:05
Subject:
Re: Review of `defer` (was: FINALLY - ready for comments/review)
Message ID:
20210806180457.323b1131@shy.leonerd.org.uk
On Fri, 6 Aug 2021 07:46:47 +0000
Nicholas Clark <nick@ccl4.org> wrote:

> I did raise a couple of questions in the previous thread that seem to
> have got missed (so don't have answers):
> 
> https://www.nntp.perl.org/group/perl.perl5.porters/2021/07/msg260747.html

Oops - I somehow manage to have missed those; let me reply here below
first:

> The one that bugs me most is:
> 
> 
> I think that this would be the first time in perl that the behaviour
> between `eval` and not eval differs. In that without eval:
...
> I'm struggling to suggest a better solution. I *think* that possibly
> $@ ought to be the *first* error encountered. As Klortho glibly put
> it:
> 
> #11916 Always ignore the second error message unless the meaning is
> obvious
> 
> but what's bugging me is that the second (or subsequent errors) might
> be fallout from the problem that caused the first exception and error
> message, but if that error message is lost (and not reported) it
> could be rather hard to figure out that actual problem.

Yes; at the moment those are literally dropped on the floor. Perhaps we
could do another warning with prefix like we do with "(in cleanup)" now?

> Do we also need to create a variable @@ which exposes the stack of
> exceptions encountered? (With $@ set to one of them, last as you
> currently have it, first as I'm suggesting, and unchanged for
> existing problematic situations, such as exceptions firing in DESTROY)

A stack of exceptions.. hmmm..

I had a grander plan with these, which involved first getting some sort
of core exception type as a real object. That would solve lots of core
problems, plus make type `catch` more useful, and would allow an
exception object to represent "nested exception".

I'm not sure I like the idea of allowing an exception stack just to
workaround this (temporary?) situation wherein we don't have exception
objects yet.

Perhaps a nicer stepping stone would be to go with the prefixed-warning
approach; so e.g. an example would look like:

  {
    defer { die "Second failure"; }
    die "First failure";
  }

  (during deferred cleanup) Second failure at example line 2.
  First failure at example line 3.

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/

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