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.
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.
You're always welcome to write a replacement if you find it unsuitable.
Coincidentally I was annoyed by this very fact a few years ago so I developed 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.
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#issuec...