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