Skip Menu |
Report information
Id: 68320
Status: open
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: missingthepoint <ben [at]>

Severity: (no value)
Tag: Todo
Platform: (no value)
Patch Status: (no value)
VM: (no value)

Subject: [BUG] TODO: $!.pending not implemented (yet)
Date: Sat, 08 Aug 2009 17:50:52 +1000
To: rakudobug [...]
From: ben [...]
Download (untitled) / with headers
text/plain 148b
eval 'widdle()'; eval 'waddle()'; say "pending: " ~ $!.pending.perl; ... gives ... Method 'pending' not found for invocant of class 'Exception'
RT-Send-CC: perl6-compiler [...]
Download (untitled) / with headers
text/plain 590b
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
Download (untitled) / with headers
text/plain 1.3k
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<@![0]>. (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)

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at