async/await improvements

[Jeff Morrison]

On 11/12/14, 5:23 PM, Tab Atkins Jr. wrote:
> On Wed, Nov 12, 2014 at 2:15 PM, Jeff Morrison <lbljeffmo at gmail.com> wrote:
>> On 11/12/14, 4:10 PM, Kevin Smith wrote:
>>> The only thing they couldn't do (under this proposal) is expose the
>>> promise being used to userland (to eliminate the chance for userland to hold
>>> on to the promise and expect to be able to add an error handler at any
>>> time).
>> And lose the ability to combine the results of async functions with "all",
>> "race", and any other promise combinator?  That's a core strength of the
>> current design.
>>
>> A very good point.
>>
>> Crazy, half-baked idea: Move the "forwards" vs "throws/logs" distinction to
>> the callsite (in sync contexts only?) rather than the definition context as
>> was described at the beginning of this thread.
> This is already the case.  If you want the promise (which "forwards"
> errors), just call the async function normally.  If you want errors to
> throw through you like a sync function would, use the "await"
> expression (which requires you to be async as well).
Indeed you could convert the entire signature of your calling function 
(and incur all the effects on the downstream call sites in doing so), 
but I was aiming for a less intrusive escape hatch.
Additionally, if you're ever operating at a toplevel somewhere, you 
don't really have this option.
>
> Logging vs forwarding will likely be distinguished via the .done()
> method, when that happens.  That means the default is to forward
> errors, and you have to explicitly opt into logging them (or hope that
> the GC catches them and they're auto-logged).
The problem with the GC-based logging is only that it doesn't work all 
the time...and for non-obvious reasons. It's really more of a heuristic. 
The extreme case where it doesn't work has already been mentioned (if 
you want to attach an error handler later); But a less extreme case is 
one where you've done something with the promise object that 
[unintuitively] causes it not to be GC'd (read: a memory leak). It's not 
so difficult to do this on accident either -- and having such a 
non-local effect occur would be less than ideal.
>> ```
>> async function doOtherAsyncStuff() {
>>    // This stays status quo
>>    try {
>>      asyncLibrary(badData);
>>    } catch (e) {
>>      // caught!
>>    }
>> }
>> ```
> You need an "await" here, like `await asyncLibrary(badData);`, to get
> the error to turn back into a throw.
Oops, nice catch. That was a typo.
>
> ~TJ