3 ms·

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-

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
  - minitech 10y ago
    In my experience, it has too many false positives to turn on.
    - dkoston 10y ago
      Sorry to hear about your experience. Been using it for years as part of our build processes with no false positives. You're always welcome to write a replacement if you find it unsuitable.
      - minitech 10y ago
        I don’t need a replacement, just offering an explanation for why some people’s needs might not be satisfied by this rule.
  - WorldMaker 10y ago
    The time this bit me the most the error was swallowed in a dependency of a dependency of a gulp plugin. Do you also eslint node_modules//*.js?
femto113 10y ago
In some scenarios, particularly when writing scripts, error handling boilerplate code tends to obscure the nominal flow, which can make the script overall harder to debug and thus net more likely to have errors. Coincidentally I was annoyed by this very fact a few years ago so I developed https://www.npmjs.com/package/callback-wrappers https://www.npmjs.com/package/callback-wrappers which made the boilerplate for common error handling scenarios (logging, throwing, exiting, emitting, etc.) much terser and moves it to the end of the functions so it's less in your face. Never made much use of it, and it's so non-canonical that I'm loathe to advocate it too much, but it would make me happy some sort of standard syntactic sugar could be introduced that allowed comparable brevity.

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
- minitech 10y ago
  In my experience, it has too many false positives to turn on.
  - dkoston 10y ago
    Sorry to hear about your experience. Been using it for years as part of our build processes with no false positives. You're always welcome to write a replacement if you find it unsuitable.
    - minitech 10y ago
      I don’t need a replacement, just offering an explanation for why some people’s needs might not be satisfied by this rule.
- WorldMaker 10y ago
  The time this bit me the most the error was swallowed in a dependency of a dependency of a gulp plugin. Do you also eslint node_modules//*.js?

femto113 10y ago

In some scenarios, particularly when writing scripts, error handling boilerplate code tends to obscure the nominal flow, which can make the script overall harder to debug and thus net more likely to have errors. Coincidentally I was annoyed by this very fact a few years ago so I developed https://www.npmjs.com/package/callback-wrappers https://www.npmjs.com/package/callback-wrappers which made the boilerplate for common error handling scenarios (logging, throwing, exiting, emitting, etc.) much terser and moves it to the end of the functions so it's less in your face. Never made much use of it, and it's so non-canonical that I'm loathe to advocate it too much, but it would make me happy some sort of standard syntactic sugar could be introduced that allowed comparable brevity.