Front page | perl.perl5.porters |
Postings from August 2021
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