3 ms·
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 thr
by nvivo 11y ago
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.
The fact that you call a method that returns a promise but don't check this promise may be a little confusing to someone new to the language, but it it's not a flaw in the design.
In c#, any attemp to call a method that returns tasks (promise) without an await or a .continueWith (.then) causes a compiler warning. It's just a matter of time for tooling in the browser to keep up.
- jlongster 11y ago> 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.
- nvivo 11y agoIndeed 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.