On Wed, Nov 12, 2014 at 2:15 PM, Jeff Morrison <lbljef...@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).
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).
> ```
> 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.
~TJ
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
