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

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

Thread Previous | Thread Next
Paul "LeoNerd" Evans
August 6, 2021 17:05
Re: Review of `defer` (was: FINALLY - ready for comments/review)
Message ID:
On Fri, 6 Aug 2021 07:46:47 +0000
Nicholas Clark <> wrote:

> I did raise a couple of questions in the previous thread that seem to
> have got missed (so don't have answers):

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

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

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