3 ms·

Wait, isn’t awaiting inside the try{} exactly how you’re supposed to handle it in the first place? Assuming you’re using await and not .catch(). And if you awai

Wait, isn’t awaiting inside the try{} exactly how you’re supposed to handle it in the first place? Assuming you’re using await and not .catch(). And if you await without the try/catch you just end up with an unhandled exception at the await, no? I’ve yet to see any junior devs make the mistake of try-ing an unawaited promise. They’ve all seemed to appreciate the “async” aspect of the semantics up front.

nosianu 5y ago
Remember that the context of this discussion is achieving parallelism by not waiting - instead, you create promises in parallel, pass them on, and attach handlers at some later point, e.g. after collecting them in a Promise.all(). As I said, as long as you do standard stuff, which for try/catch in an async function and an "await" of all promises is the standard path. Sometimes people create a promise without awaiting inside a try/catch, thinking they got errors handled, because they don't want to wait but start another promise-producing function right away. But that other function needs its own catch handler so they write another one below the first one and don't "await" to get both asynchronous promise-returning functions to run simultaneously without the second one having to wait for the first one, because what they do is independent (so far the thoughts are correct and good). Since they use try/catch instead of the .then() and .catch() handler and they don't fully understand all the implications they run into this problem. It happened to me when I learned promises, after already having programmed with them for well over a year and feeling comfortable, and it just recently happened to some of my people (it no longer happens to me, it's the next generations turn...). Other issues that make this exact problem insidious are: - This problem can only be spotted when the promise is rejected. If your tests don't include that you will only see it when someone runs into this issue by chance, much later, maybe in production. - Often it may not get fixed even after there is a rejected promise showing the problem. What time-limited stressed middle-level developers will do is solve the rejected promise but not the way it isn't caught. The code construct that lead to "uncaught promise rejection" will remain unfixed though, because as soon as the promise no longer rejects the code appears to work fine.
- munchbunny 5y ago
  > Remember that the context of this discussion is achieving parallelism by not waiting - instead, you create promises in parallel, pass them on, and attach handlers at some later point, e.g. after collecting them in a Promise.all(). Aren't "await Promise.all(...)" and "Promise.all(...).then(...)" more or less equivalent? (I'm less familiar with how JavaScript handles it under the hood.) In one case the callback executes once the promise completes, in another case execution of code after the await resumes once the promise completes. The article was about only awaiting once you actually need the data, whether you do it with continuation passing or async/await seems like an unimportant detail.
  - nosianu 5y ago
    The discussion is about when you attach handlers, and failure handlers specifically. When someone uses async/await style and try/catch but also adds in handling (passing) actually promises, without await-ing them.

nosianu 5y ago

Remember that the context of this discussion is achieving parallelism by not waiting - instead, you create promises in parallel, pass them on, and attach handlers at some later point, e.g. after collecting them in a Promise.all(). As I said, as long as you do standard stuff, which for try/catch in an async function and an "await" of all promises is the standard path. Sometimes people create a promise without awaiting inside a try/catch, thinking they got errors handled, because they don't want to wait but start another promise-producing function right away. But that other function needs its own catch handler so they write another one below the first one and don't "await" to get both asynchronous promise-returning functions to run simultaneously without the second one having to wait for the first one, because what they do is independent (so far the thoughts are correct and good). Since they use try/catch instead of the .then() and .catch() handler and they don't fully understand all the implications they run into this problem. It happened to me when I learned promises, after already having programmed with them for well over a year and feeling comfortable, and it just recently happened to some of my people (it no longer happens to me, it's the next generations turn...). Other issues that make this exact problem insidious are: - This problem can only be spotted when the promise is rejected. If your tests don't include that you will only see it when someone runs into this issue by chance, much later, maybe in production. - Often it may not get fixed even after there is a rejected promise showing the problem. What time-limited stressed middle-level developers will do is solve the rejected promise but not the way it isn't caught. The code construct that lead to "uncaught promise rejection" will remain unfixed though, because as soon as the promise no longer rejects the code appears to work fine.

munchbunny 5y ago
> Remember that the context of this discussion is achieving parallelism by not waiting - instead, you create promises in parallel, pass them on, and attach handlers at some later point, e.g. after collecting them in a Promise.all(). Aren't "await Promise.all(...)" and "Promise.all(...).then(...)" more or less equivalent? (I'm less familiar with how JavaScript handles it under the hood.) In one case the callback executes once the promise completes, in another case execution of code after the await resumes once the promise completes. The article was about only awaiting once you actually need the data, whether you do it with continuation passing or async/await seems like an unimportant detail.
- nosianu 5y ago
  The discussion is about when you attach handlers, and failure handlers specifically. When someone uses async/await style and try/catch but also adds in handling (passing) actually promises, without await-ing them.