> About the points you make on your post, once async/await is implemented in browsers, you will be able to await run() directly, causing the exception to be thrown in the console.
I don't think you're right, unless TC39 has changed their minds. I argued hard for a top-level `await` but was strongly fought back.
If you can call into an async function in a way that immediately throws errors (that means that we can literally check the stack if the current async function should just throw the error), then I'm all good.
Indeed that might be the case. There are ES6 features implemented in chrome that don't work in the console (eg. classes). Still, it doesn't mean the language or the feature is doomed.
You have exactly the same issue with setTimeout. Errors will be thrown when the function runs, not when you schedule it. The problem you're describing is not an issue, and that's why today there are linters and compilers.
I don't think you're right, unless TC39 has changed their minds. I argued hard for a top-level `await` but was strongly fought back.
If you can call into an async function in a way that immediately throws errors (that means that we can literally check the stack if the current async function should just throw the error), then I'm all good.