This queue is for tickets about the Future-AsyncAwait CPAN distribution.

Report information
The Basics
Id:
129305
Status:
resolved
Priority:
Low/Low

People
Owner:
Nobody in particular
Requestors:
leonerd-cpan [...] leonerd.org.uk
Cc:
AdminCc:

BugTracker
Severity:
Wishlist
Broken in:
(no value)
Fixed in:
(no value)



Subject: Think about ->fail additional results
sub bork { return Future->fail( "failure message", thing => $other, $values, $! ); } as compared async sub bork { die "failure message"; } Where do we notate the remaining list items? -- Paul Evans
Additionally, $f->else(sub { my ( $message, $category, @additional ) = @_; ... }); vs try { await $f; } catch { my $message = $@; } where do I access $category and @additional ? -- Paul Evans
ilmari suggests a simple solution to the first case at least. die [ $message, category => @additional ]; Which: * looks neat and tidy * doesn't introduce any new keywords or syntax * is simple to implement -- Paul Evans
The more I stare at this the more I feel it's actually a missing feature in Future itself. It can be see in a plain Future + SKT example: try { Future->fail( "message", category => @details )->get; } catch { # where's the details now? } If Future->get wrapped the additional results in some sort of exception object (with stringification overloading for back compat), then they'd be visible in $@: ... catch { say "The Future failure category was " . $@->category; } Having done that, then F-AA needs to do nothing further for the `await` case. The other half of the problem, of how `async sub` can yield those, can also be solved if Future->fail($err) could recognise its own exception objects and unfold them again: catch { Future->fail($@); } would then be transparent to Future failures. Since F-AA itself is transparent to non-stringy object references as exceptions, this behaviour would combine nicely, and pass additional results through without AsyncAwait.xs itself having to make special consideration of it. I like this "no tricks up my sleeve" approach, as it allows other implementations to do the same thing, and helps limit the "unwarranted chumminess with Future implementation" problem. -- Paul Evans
With Future 0.40 this now works as intended, with no code change required in F-AA itself. -- Paul Evans


This service runs on Request Tracker, is sponsored by The Perl Foundation, and maintained by Best Practical Solutions.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.