Details about the rejectionUnhandled events dont seem to be in the docs yet, but this gist [1] explains it in detail. Looks like a decent solution to quiet suppression of unhandled rejections.
We're interested in feedback on how the event descriptions are phrased since there is some controversy regarding how these events "should be used" - if anyone has any feedback on phrasing or how to explain the usage of these events better I'd love to know how to improve them more.
Hang on - 1.3 was only about three days ago! Rapid progress is obviously fantastic, but is there a reason why these two releases weren't bundled together?
Probably due to V8 upgrade which contains an embargoed fix. These are usually critical bugs that remain undisclosed until major users (read as: large companies) have patched their systems.
Great question. It started off as 1.3.x but ended up being 1.4 for semver issues. There was discussion[1] about this. In short - it was named 1.4 because of how NPM updated and because of the big features landing.
Not really unfortunate. Unlike with money, inflation of version numbers doesn't cause that much trouble. It just takes some getting used to. I've gotten used to the high version numbers in Chrome and Firefox, and I'm sure I'll get used to them in projects that use semver the right way as well.
In Google's defence - they have stated they won't support versions of v8 that reached end of life and have announced they're supporting io.js in favor of node. I totally get why Google won't backport fixes like this.
Google is actively helping io.js and development is coordinated.
To be clear, I find it annoying Google is not yet making the bug public even though the fix and test driver are available. Since they aren't going to patch the v8 in Node, I'd think Node users would really like to know if they are vulnerable to this and should manually patch it. stares at Joyent
Is this two releases in a row now that have had a major issue due to speed of release and lack of testing?
Seriously I think it is great to push the platform forward but this is exactly what Joyent was cautious about. Solves some bugs but creates other less predictable problems.
Current node-debugger still does not work with io.js so I am curious how the feature is debuggable.
Trevor Norris informed me that C++11 must be supported for the version of v8 that iojs ships with, which means node native module authors can use C++11. The native stream stuff looks neat, too. As an author of a node native add on, I look forward to this iojs/node fork stuff being resolved, so that I can start using new features. Until then, I refuse to make drop support for node.js.
...the idea being that it's analogous to an uncaught exception bubbling up to the top and causing the process to crash, which is generally what you want to happen?
Yes, it's possible this indeed will be the default behavior at some later point.
Some people don't like this since `unhandledRejection`s can be handled later on at some point (for example, after a week of not adding a catch handler).
22 comments
[ 2.0 ms ] story [ 72.8 ms ] thread1 https://gist.github.com/benjamingr/0237932cee84712951a2
We're interested in feedback on how the event descriptions are phrased since there is some controversy regarding how these events "should be used" - if anyone has any feedback on phrasing or how to explain the usage of these events better I'd love to know how to improve them more.
Edit: five days ago, but my point stands.
[1] https://github.com/iojs/io.js/issues/932
https://github.com/joyent/node/blob/master/deps/v8/src/heap/...
assuming this is the issue:
https://github.com/iojs/io.js/pull/952/files#diff-1440e8305d...
It is kind of annoying that the bug is embargoed...
Google is actively helping io.js and development is coordinated.
Edit: They force pushed to master to remove the release due to issues on OSX
https://github.com/iojs/io.js/issues/932#issuecomment-760480...
Seriously I think it is great to push the platform forward but this is exactly what Joyent was cautious about. Solves some bugs but creates other less predictable problems.
Current node-debugger still does not work with io.js so I am curious how the feature is debuggable.
Any speed improvements to the ArrayBuffers? http://geekregator.com/2015-01-19-node_js_and_io_js_very_dif... For us with Clara.io, TypedBuffers are pretty important.
Some people don't like this since `unhandledRejection`s can be handled later on at some point (for example, after a week of not adding a catch handler).
There is a discussion here: https://github.com/iojs/io.js/issues/830
``` io.js ChangeLog 2015-02-20, Version 1.3.0, @rvagg ```