On 11/12/14, 5:23 PM, Tab Atkins Jr. wrote:
On Wed, Nov 12, 2014 at 2:15 PM, Jeff Morrison <[email protected]> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
