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

On Mon, Oct 17, 2016 at 7:40 AM, Jordan Rome <jor...@jordanrome.com> wrote:

> On Sun, Oct 16, 2016 at 9:14 AM, Marky Mark <m...@heyimmark.com> 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

Reply via email to