5 ms·

Because it's not just an 'ignoring of errors', it's the fact all exceptions (as in actual errors from the runtime) are silently swallowed. In your example, if y

Because it's not just an 'ignoring of errors', it's the fact all exceptions (as in actual errors from the runtime) are silently swallowed. In your example, if you typo in that function body, an exception will be thrown, your program will exit and you will see the stacktrace. var fs = require('fs'); fs.writeFile('foo.data', function(err){ // A typo here will lead to an exit and stacktrace sadsad }); Whereas in the Promise examples it is quite literally silently swallowing ALL exceptions thrown, including typos etc. It is limited to Promises, because they're supposed to help us deal with error propagation, and pass exceptions through to `.catch()` handlers. But if that catch handler is missing, crickets, even for outright invalid code. That doesn't happen with any other construct in JS afaik.

WorldMaker 10y ago
In that example the same error gets thrown with a Promise because you're talking about mostly a JIT error at file load time. (Promise.resolve().then(() => I am a syntax error)) The parent's point is that you still aren't doing anything with the callback errors (that first parameter to most node-style callbacks) and those silent swallows are a lot harder to deal with than Promise's silent swallows because node callback error handling is a convention that is easily missed/forgotten/ignored, whereas Promises always "bubble" exceptions "down the chain" and fixing global unhandled exception handlers in Promises is a lot easier (and done at a platform level) than fixing a codebase full of bad node-style callbacks.
- nilliams 10y ago
  I disagree. A developer choosing to not handle the 'error' param in an error-first callback at all is incompetence from a node dev, akin to writing 'try-except-pass' in Python, whereas silent swallowing of runtime exceptions is a bug of the runtime and inexcusable. Btw, I prefer Promises and the error-bubbling approach in principle for the reasons you're getting at, but the current implementations (especially in p0lyfills like es6-promise) are simply broken, due to the standards themselves being lacking. See this comment for fact the fix has been in draft for a while now: https://github.com/stefanpenner/es6-promise/issues/70#issuecomment-223898502 https://github.com/stefanpenner/es6-promise/issues/70#issuec...
  - WorldMaker 10y ago
    I disagree. Developers are human and if they have to remember to write extra code to get a thing to do the right thing, they are likely to forget. (try-except-pass is an explicit opt out; if (err) throw err is a "required" opt in.) This "bug" in some of the Promise runtimes could just as easily be handled by forcing every Promise chain to end in a .catch((err) => /* ... */). Requiring even this little bit is less onerous than node-style callbacks where every "link in the chain" needs explicit opt-in, with Promises you only "have to" opt in and deal with boundaries, just like try-catch in most languages. Yes, it's not great that Node and some of the browsers initially "missed" the "great try/catch in the sky" catch all logging, but again that is easily resolved at the runtime platform level whereas node can't possibly tell you if a developer missed an if (err) throw err somewhere in a callback chain 10-levels deep and across three or four dependencies.
    - nilliams 10y ago
      I agree that handling promises should be by default better than remembering to 'if (err) throw err' but my original comment was about how spec-adhering promise polyfills like es6-promise are basically broken because they silently swallow the most egregious errors. They silently swallow all runtime exceptions, not 'error from reading said file you told me to read, that there should, by any sane degree be SOME KIND of error handling for, and for anyone serious about programming in a dynamic language, also test coverage for'. Those two things are different issues, on different levels. > Yes, it's not great that Node and some of the browsers initially "missed" the "great try/catch in the sky" catch all logging, but again that is easily resolved at the runtime platform level That's all my original comment said. The platforms (actually the spec) failed to get it right initially, the implementation was broken and now it is fixed.
    - dkoston 10y ago
      Seriously? It takes 5 seconds to add an eslint rule to avoid this issue. http://eslint.org/docs/rules/handle-callback-err http://eslint.org/docs/rules/handle-callback-err
      - 10y ago
_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
Touche 10y ago
Personally I don't want my process to crash because I didn't handle some unimportant writeFile call correctly. This is why I use Promises, so I can handle exceptions.
- deleted 10y ago
  [deleted]

WorldMaker 10y ago

In that example the same error gets thrown with a Promise because you're talking about mostly a JIT error at file load time. (Promise.resolve().then(() => I am a syntax error)) The parent's point is that you still aren't doing anything with the callback errors (that first parameter to most node-style callbacks) and those silent swallows are a lot harder to deal with than Promise's silent swallows because node callback error handling is a convention that is easily missed/forgotten/ignored, whereas Promises always "bubble" exceptions "down the chain" and fixing global unhandled exception handlers in Promises is a lot easier (and done at a platform level) than fixing a codebase full of bad node-style callbacks.

nilliams 10y ago
I disagree. A developer choosing to not handle the 'error' param in an error-first callback at all is incompetence from a node dev, akin to writing 'try-except-pass' in Python, whereas silent swallowing of runtime exceptions is a bug of the runtime and inexcusable. Btw, I prefer Promises and the error-bubbling approach in principle for the reasons you're getting at, but the current implementations (especially in p0lyfills like es6-promise) are simply broken, due to the standards themselves being lacking. See this comment for fact the fix has been in draft for a while now: https://github.com/stefanpenner/es6-promise/issues/70#issuecomment-223898502 https://github.com/stefanpenner/es6-promise/issues/70#issuec...
- WorldMaker 10y ago
  I disagree. Developers are human and if they have to remember to write extra code to get a thing to do the right thing, they are likely to forget. (try-except-pass is an explicit opt out; if (err) throw err is a "required" opt in.) This "bug" in some of the Promise runtimes could just as easily be handled by forcing every Promise chain to end in a .catch((err) => /* ... */). Requiring even this little bit is less onerous than node-style callbacks where every "link in the chain" needs explicit opt-in, with Promises you only "have to" opt in and deal with boundaries, just like try-catch in most languages. Yes, it's not great that Node and some of the browsers initially "missed" the "great try/catch in the sky" catch all logging, but again that is easily resolved at the runtime platform level whereas node can't possibly tell you if a developer missed an if (err) throw err somewhere in a callback chain 10-levels deep and across three or four dependencies.
  - nilliams 10y ago
    I agree that handling promises should be by default better than remembering to 'if (err) throw err' but my original comment was about how spec-adhering promise polyfills like es6-promise are basically broken because they silently swallow the most egregious errors. They silently swallow all runtime exceptions, not 'error from reading said file you told me to read, that there should, by any sane degree be SOME KIND of error handling for, and for anyone serious about programming in a dynamic language, also test coverage for'. Those two things are different issues, on different levels. > Yes, it's not great that Node and some of the browsers initially "missed" the "great try/catch in the sky" catch all logging, but again that is easily resolved at the runtime platform level That's all my original comment said. The platforms (actually the spec) failed to get it right initially, the implementation was broken and now it is fixed.
  - dkoston 10y ago
    Seriously? It takes 5 seconds to add an eslint rule to avoid this issue. http://eslint.org/docs/rules/handle-callback-err http://eslint.org/docs/rules/handle-callback-err
    - 10y ago

_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

Touche 10y ago

Personally I don't want my process to crash because I didn't handle some unimportant writeFile call correctly. This is why I use Promises, so I can handle exceptions.

deleted 10y ago
[deleted]