Skip Menu |
 

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

Report information
The Basics
Id: 129305
Status: resolved
Priority: 0/
Queue: Future-AsyncAwait

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

Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in: (no value)



Subject: Think about ->fail additional results
Download (untitled) / with headers
text/plain 209b
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
Download (untitled) / with headers
text/plain 231b
Additionally, $f->else(sub { my ( $message, $category, @additional ) = @_; ... }); vs try { await $f; } catch { my $message = $@; } where do I access $category and @additional ? -- Paul Evans
Download (untitled) / with headers
text/plain 233b
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
Download (untitled) / with headers
text/plain 1.2k
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
Download (untitled) / with headers
text/plain 106b
With Future 0.40 this now works as intended, with no code change required in F-AA itself. -- Paul Evans


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

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