Just because you get a message in your console that you have an unhandled rejection, doesn't mean your program can adapt to that as needed. Relying on that information is a last resort - it's the final safety net for you, the human, if you've failed to .catch all your promises at runtime (in your code).
On Mon, Oct 17, 2016 at 7:40 AM, Jordan Rome <[email protected]> wrote: > > On Sun, Oct 16, 2016 at 9:14 AM, Marky Mark <[email protected]> wrote: > >> But if you dont, your program will never know about the error or do >> anything to handle it. > > > Perhaps this is where I'm confused. I'm under the impression that `catch` > shouldn't be used anymore than try/catch does when you're writing > synchronous code. I usually end up using try/catch only when there is a > higher likelihood of programmer error (e.g. JSON.parse). If my program > happens to throw, I don't just wrap that bit of code in another try/catch > but I go and fix whatever was causing the throw (if fixable). I don't quite > see how this changes with Promises or async code in general as I see a lot > of folks adding catch and wrapping `await` in try/catch -- claiming that > it's* "very important" *to do this (quoting Alan above). Perhaps this is > from a time when Promises were swallowing errors and not reporting > unhandled rejections but it seems like browsers and node are fixing or have > fixed this issue. So, if my Promise chain rejects and I have not caught it, > I would just go in and fix whatever was throwing/rejecting (again, if > fixable). > > -- > Best, > > Jordan Rome > www.jordanrome.com >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
