On Sat Aug 08 00:51:28 2009, missingthepoint wrote:
Show quoted text
> eval 'widdle()';
> eval 'waddle()';
> say "pending: " ~ $!.pending.perl;
> ... gives ...
> Method 'pending' not found for invocant of class 'Exception'
I believe this now needs a try, but is still todo:
19:07 < [Coke]> rakudo: try eval 'waddle()'; say "pending: " ~ $!.pending.perl;
19:07 <+p6eval> rakudo 38907e: OUTPUT«Method 'pending' not found for invocant
of class 'Exception'␤ in block <anon> at /tmp/bQT6MmUmQC:1␤
in <anon> at /tmp/bQT6MmUmQC:1␤»
Will "Coke" Coleda
#Mon, 10 Oct 2011 16:07:55 -0700The RT System itself - Status changed from 'new' to 'open'
#Mon, 10 Oct 2011 16:08:06 -0700Will Coleda <firstname.lastname@example.org> - Tag Todo added
#Mon, 10 Oct 2011 16:08:06 -0700Will Coleda <email@example.com> - Tag Bug deleted
#Mon, 10 Oct 2011 16:08:25 -0700Will Coleda <firstname.lastname@example.org> - Subject changed from '[BUG] TODO: $!.pending not implemented (yet)' to '[TODO] $!.pending'
#Wed, 10 Feb 2016 21:11:00 -0800"Brian S. Julin" <email@example.com> - Correspondence added[Reply] [Comment]
It seems that long since any mention of $!.pending was
removed from the design docs. However, roast has
S04-exceptions/pending.t and this file has (fudged)
tests for that... and this file seems to be in the
6.c roast branch as well.
So this boils down to two questions:
1) What's the meaning of a *fudged* test in 6.c. Since the fudge
is implementation-specific, probably we have promised $!.pending to users now.
2) What's the use case for $!.pending and if/how this is to be satisfied.
Note there is now this conjecture in S04:
[Conjecture: all unhandled exceptions within a routine could be stored in
C<@!>, with the most recent first. C<$!> would then be sugar for C<@!>.
(Or we use push semantics and C<$!> means C<@![*-1]>.) This might be more
robust than merely making C<@!> a parameter to CATCH. However, the new
semantics of autothrowing when sink eats a Failure means we won't have many
unthrown exceptions waiting around to be handled at the end of the block
anymore. We should probably at least issue warnings, though, if the GC
eventually collects a failure that was never handled. We can't really rely
on end-of-routine cleanup to deal with failures that are returned as normal
data, unless we go with the overhead of a lexical C<@!> variable.]
(There's no special reason for bumping this old ticket I was just bored)