5 ms·

> it is quite literally silently swallowing ALL exceptions thrown Technically, it propagates the error along to any dependent promises. If nobody's handling er

by _greim_ 10y ago

> it is quite literally silently swallowing ALL exceptions thrown Technically, it propagates the error along to any dependent promises. If nobody's handling errors, then yes, they get swallowed. If that bugs you, all you have to do is add this once when your app starts up: process.on('unhandledRejection', function(ex) { console.error(ex.stack); process.exit(1); }); I think that should have been the default, personally, but it's a nuisance at worst. Throwing out promises because of this is absurd thinking.

james-mcelwain 10y ago
Killing a process on an exception you can't handle is sort of best practice anyway in Node--assuming you're not building important financial services or whatever in Node (lol). Like, you want to be careful not to open yourself up to cascading failure, but if my application has a random exception, the 100ms start up time of the JavaScript VM means its almost always worth the cost of restarting to ensure your application isn't in an unstable state.
- Touche 10y ago
  What makes you think I can't handle it? I definitely can handle it, and Promises give me the ability to handle them.
  - deleted 10y ago
    [deleted]
- danneu 10y ago
  I'd rethink that. Every connection to the server closes, and whatever else it might be doing stops, because someone hits your syntax error? And they completely DoS your server by slowly refreshing the page? Surely the best practice is to use something like koa or otherwise create a promise chain with a top-level 500 handler.
  - mnutt 10y ago
    Depending on how much state your applications carry forward, I think killing the process is often the right thing to do. Otherwise, it's very easy to end up with connection leaks or just downright confusing state that can't always easily be traced back to what should have been an exception. I run a node app that serves ~500M requests a day that is configured to die on exceptions, it just means that we do everything we can to prevent them (unit tests, linters, etc) and take them very seriously when they happen.
nilliams 10y ago
In my example I was talking about avoiding es6-promise polyfill in the browser, because of the fact that it adheres so strictly to the spec that it does not have an equivalent to the safety net you give in your Node example.
- _greim_ 10y ago
  Yeah polyfills might not do the right thing. Natively, both exceptions and rejections stop the next thing from happening, give you a trace in the console, then everything continues at the next tick of the event loop. If a polyfill skips the trace part, that's definitely bad.
  - nilliams 10y ago
    Yep I know, I'm specifically complaining about the current trend of casting off old ajax methods/libraries and moving to 'fetch()' polyfills, as currently the 2 main popular fetch modules both recommend 'es6-promise' as polyfill which has serious problems in this regard: https://github.com/matthew-andrews/isomorphic-fetch/issues/111 https://github.com/matthew-andrews/isomorphic-fetch/issues/1... Technically however, what that polyfill is doing is 'on-spec'. Note that your `process.on('unhandledRejection')` thing is clearly outside spec as `process` is a Node thing, not a JS thing.

by _greim_ 10y ago

james-mcelwain 10y ago

Killing a process on an exception you can't handle is sort of best practice anyway in Node--assuming you're not building important financial services or whatever in Node (lol). Like, you want to be careful not to open yourself up to cascading failure, but if my application has a random exception, the 100ms start up time of the JavaScript VM means its almost always worth the cost of restarting to ensure your application isn't in an unstable state.

Touche 10y ago
What makes you think I can't handle it? I definitely can handle it, and Promises give me the ability to handle them.
- deleted 10y ago
  [deleted]
danneu 10y ago
I'd rethink that. Every connection to the server closes, and whatever else it might be doing stops, because someone hits your syntax error? And they completely DoS your server by slowly refreshing the page? Surely the best practice is to use something like koa or otherwise create a promise chain with a top-level 500 handler.
- mnutt 10y ago
  Depending on how much state your applications carry forward, I think killing the process is often the right thing to do. Otherwise, it's very easy to end up with connection leaks or just downright confusing state that can't always easily be traced back to what should have been an exception. I run a node app that serves ~500M requests a day that is configured to die on exceptions, it just means that we do everything we can to prevent them (unit tests, linters, etc) and take them very seriously when they happen.

nilliams 10y ago

In my example I was talking about avoiding es6-promise polyfill in the browser, because of the fact that it adheres so strictly to the spec that it does not have an equivalent to the safety net you give in your Node example.

_greim_ 10y ago
Yeah polyfills might not do the right thing. Natively, both exceptions and rejections stop the next thing from happening, give you a trace in the console, then everything continues at the next tick of the event loop. If a polyfill skips the trace part, that's definitely bad.
- nilliams 10y ago
  Yep I know, I'm specifically complaining about the current trend of casting off old ajax methods/libraries and moving to 'fetch()' polyfills, as currently the 2 main popular fetch modules both recommend 'es6-promise' as polyfill which has serious problems in this regard: https://github.com/matthew-andrews/isomorphic-fetch/issues/111 https://github.com/matthew-andrews/isomorphic-fetch/issues/1... Technically however, what that polyfill is doing is 'on-spec'. Note that your `process.on('unhandledRejection')` thing is clearly outside spec as `process` is a Node thing, not a JS thing.