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.
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.
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.