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
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 to always be
wrapping
10 matches
Mail list logo
