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
c
On Sun, Oct 16, 2016 at 9:14 AM, Marky Mark 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
synchrono
On Sun, Oct 16, 2016, 5:32 AM Jordan Rome wrote:
>
> I'm still confused as to why it's important to always try/catch (or even
> catch for promises) if you get an error message in the console (vs calling
> console.error manually).
>
You don't always have to catch promise errors. It's entirely opt
On Sat, Oct 15, 2016 at 11:40 PM, Jordan Harband wrote:
> When the await throws an exception that's not caught by a try/catch, the
> promise returned by the `async function` ends up rejected - and you have
> the identical scenario as a promise with an unhandled rejection.
>
Ah, that's the part I
When the await throws an exception that's not caught by a try/catch, the
promise returned by the `async function` ends up rejected - and you have
the identical scenario as a promise with an unhandled rejection.
node has been discussing adding "crash on garbage collection of an
unhandled rejection"
On Fri, Oct 14, 2016 at 11:25 AM, Alan Johnson wrote:
> Having unexpected errors be silently swallowed is definitely a problematic
> property of promises, which you have to guard against.
I didn't think this was the case with await. If a promise rejection is not
caught the await throws an excep
Just one thought:
> Of course, in the top-level invocation it might be a good idea to use a
`catch`
after years of engine developers advocating "avoid try/catch as much as
possible because it de-opts and slow down code and JIT and you name it",
above suggestion doesn't really look like an "of cou
To perhaps clarify this point a bit, it is very important to `.catch()` and
react appropriately at the ends of promise chains. If synchronous code fails
for an unexpected reason, a visible crash will definitely happen. This is not
the case for promises, because there’s no way for the runtime to
Jordan Rome schrieb:
My apologies if this has already been discussed but what is the "preferred"
pattern for using await ? Since await, which runs on promises, will now
throw if the promise is rejected (preventing execution of code after the
await and killing the process in Node), is it neccesary
9 matches
Mail list logo