3 ms·

http://jlongster.com/Stop-Trying-to-Catch-Me http://jlongster.com/Stop-Trying-to-Catch-Me

Sir_Cmpwn 11y ago
I don't really agree with the points this post puts forth, but I also don't really think this is the place to discuss it.
- grandalf 11y ago
  This is a great place to discuss it.
  - Sir_Cmpwn 11y ago
    I just didn't want to get into the weeds about why his blog post is wrong here. In any case, his arguments against try...catch are silly. Syntax errors are not an argument against them, because you can easily detect them with other tools (and should be doing so). In practice, the only errors that will bubble up to your try...catch are ones about the async operation, not "typos".
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 ago
    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 really agree with the points this post puts forth, but I also don't really think this is the place to discuss it.

grandalf 11y ago
This is a great place to discuss it.
- Sir_Cmpwn 11y ago
  I just didn't want to get into the weeds about why his blog post is wrong here. In any case, his arguments against try...catch are silly. Syntax errors are not an argument against them, because you can easily detect them with other tools (and should be doing so). In practice, the only errors that will bubble up to your try...catch are ones about the async operation, not "typos".

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 ago
  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.