<div dir="ltr">Hi James,<div><br></div><div>As you point out, exception swallowing is a problem for promises in general.  The best way to approach the issue as it applies to async/await is to just solve it for promises.  The current direction JS engines are taking is to log unhandled rejections in one way or another.  I would keep an eye on those developments.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 12, 2014 at 1:33 AM, James Long <span dir="ltr"><<a href="mailto:longster@gmail.com" target="_blank">longster@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">After a brief twitter conversation last night<br>
(<a href="https://twitter.com/lbljeffmo/status/532402141001179136" target="_blank">https://twitter.com/lbljeffmo/status/532402141001179136</a>) I thought<br>
I'd post some thoughts I've been having about async/await.<br>
<br>
I feel like I'm about to walk into a pit where people throw lava at<br>
each other, but I need to see if at least a few other people agree<br>
with me.<br>
<br>
I know I'm in the minority here, but I don't like promises behavior of<br>
automatically suppressing all errors. But I know there advantages to<br>
it. Pros & cons, you know. However, recently there's been talk of<br>
adding special builtin `async` and `await` features to ES7. This is<br>
cool, except that currently they are built on top of promises, meaning<br>
you get the same suppress-error-by-default behavior.<br>
<br>
Meaning, if I had the following:<br>
<br>
async function foo() {<br>
  throw new Error('bad');<br>
}<br>
<br>
You wouldn't see this error unless you remember to somehow "end" the<br>
async chain. Am I correct in this?<br>
<br>
The thing is, I think we actually have a chance to fix this since<br>
async/await will be special builtin syntax. Let's first take a look at<br>
C# error handling behavior (which supposedly is what inspired<br>
async/await):<br>
<br>
async static void AsyncVersion() {<br>
   // uh oh error happened<br>
}<br>
<br>
The above code throws the error by default, no special handling<br>
needed. Isn't that cool? But what if you want to handle errors<br>
asynchronously? Well, C# knows that you don't return anything above,<br>
so it knows if can just throw it. If you want to forward the error,<br>
you need to return a Task:<br>
<br>
async static Task AsyncVersion() {<br>
  // throw an error<br>
}<br>
<br>
So there's actually 2 different ways to suggest how to forward/throw<br>
errors. This makes async/await insanely cool because you know at some<br>
point at the top of chain the error will always throw, since you will<br>
always be calling it from a top-level void async function.<br>
<br>
Can't we do the same with our async/await? What if we made it only<br>
possible to call async functions from other async functions, made<br>
`async function` throw by default (not forward), but introduced<br>
`async^` which would forward?<br>
<br>
async^ function foo() {<br>
  // errors here are captured and forwarded<br>
}<br>
<br>
async function foo() {<br>
  // errors here are thrown in the JS processes<br>
}<br>
<br>
This makes it the default behavior to be "forgot to forward error"<br>
instead of "forgot to log the error", which is better imho. I'm sure<br>
there are problems with this, and the community might hate it. If so<br>
please let's just move on and not make this a holy war. I can accept<br>
that the JS community has already embraced promises-style error<br>
handling. But I thought I'd throw this quick idea out there.<br>
<br>
With <3,<br>
- James<br>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div><br></div>