Thanks for this post, I do like to see people write about async/await/promises
while I agree with most of the post (all of the async/await part) I would add the following to the promises part:
When using promises always return
fetchData().then(data=>{doSomethingComplex(data);// if this is a promise, the error will be swallowed}).catch(err=>{// Errors from `fetchData` and `doSomethingComplex` end up here.});
In my opinion every error should be handled in a .catch statement and any asynchronous code inside a promise should be returned, this will prevent error swallowing (which is very common in bad written async code)
if for some reason you have to finish your chain of events sooner you can always chain .then and .catch check this repl for an example on how things can fail
Handling errors in .catch() also causes problems when you're chaining promises, as .catch always returns a resolved promise. If you're trying to chain based on the result of a promise, catch() won't behave the way you want.
catch() will swallow errors from non-asynchronous code, which is a very common use case. The code sandbox I link to shows an exception from Redux code being swallowed. I agree that any further promises should be returned, but the behavior of catch() led me to write some bugs when trying to handle errors at each step of my returned promises, rather than handling them all in a catch() at the end.
If you saw the repl I linked, catch does not swallow non async errors and returning the promise in a catch is something meant to let the user handle the program's flow
Not returning inside promises is the real reason stuff gets weird behaviors and error swallowing, I invite you to read the post I linked to, he makes clear these things you try to point out
The repl shows you manually throwing in catch() in order to skip the remaining then()s as well as manually returning the data, neither of which seem like a practice I'd like to use. It doesn't appear to show an example of sync code throwing an error either, which my Sandbox demonstrates will be caught. Good feedback though! I'm glad you shared your perspective.
The repl shows you manually throwing in catch() in order to skip the remaining then()s as well as manually returning the data, neither of which seem like a practice
Promises are meant to be used in a "synchronous way" because once code becomes async it can't go back to be sync, so passing stuff around is what they are meant to do.
I updated the repl throwing synchronous and asynchronously just comment and uncomment 11 and 10, 17 (which is the synchronous code that will throw synchronously inside a catch) to see what I mean.
It's nice to see different perspectives, cheers!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for this post, I do like to see people write about async/await/promises
while I agree with most of the post (all of the async/await part) I would add the following to the promises part:
When using promises always return
In my opinion every error should be handled in a .catch statement and any asynchronous code inside a promise should be returned, this will prevent error swallowing (which is very common in bad written async code)
if for some reason you have to finish your chain of events sooner you can always chain .then and .catch check this repl for an example on how things can fail
repl.it/@AngelMunoz/PromiseErrorHa...
also I would recommend the following post that gives an awesome explanation of Promises code
pouchdb.com/2015/05/18/we-have-a-p...
Cheers! keep up posting!
Handling errors in .catch() also causes problems when you're chaining promises, as .catch always returns a resolved promise. If you're trying to chain based on the result of a promise, catch() won't behave the way you want.
catch() will swallow errors from non-asynchronous code, which is a very common use case. The code sandbox I link to shows an exception from Redux code being swallowed. I agree that any further promises should be returned, but the behavior of catch() led me to write some bugs when trying to handle errors at each step of my returned promises, rather than handling them all in a catch() at the end.
If you saw the repl I linked, catch does not swallow non async errors and returning the promise in a catch is something meant to let the user handle the program's flow
Not returning inside promises is the real reason stuff gets weird behaviors and error swallowing, I invite you to read the post I linked to, he makes clear these things you try to point out
The repl shows you manually throwing in catch() in order to skip the remaining then()s as well as manually returning the data, neither of which seem like a practice I'd like to use. It doesn't appear to show an example of sync code throwing an error either, which my Sandbox demonstrates will be caught. Good feedback though! I'm glad you shared your perspective.
Promises are meant to be used in a "synchronous way" because once code becomes async it can't go back to be sync, so passing stuff around is what they are meant to do.
I updated the repl throwing synchronous and asynchronously just comment and uncomment 11 and 10, 17 (which is the synchronous code that will throw synchronously inside a catch) to see what I mean.
It's nice to see different perspectives, cheers!