Edit: Conceptually it seems the same as promises. The main difference seems to be that they've added hooks [3] into the pipeline, and they duck punch the core API to intercept errors. Bluebird has solved this without duck punching using `Promise.promisifyAll(require("fs"))` [4]. I would love to see a write up on Zone.js's forks, because the article could of trivially been rewriten to use promises.
[1] http://strongloop.com/strongblog/comparing-node-js-promises-... [2] https://github.com/kriskowal/q#long-stack-traces [3] https://github.com/btford/zone.js/#zonefork [4] https://github.com/petkaantonov/bluebird
> What we're doing is make it unnecessary to add error handlers everywhere and still get caught by surprising failure modes. If the zone catches an error it cleans up (closes resources, cancel operations when that makes sense) and then routes the error to the zone's result callback so you can handle it in once place.
I'm really unclear on how the zone library is doing the magical interception of errors. In the curl example you don't put error handlers on things. But clearly something must be. Does a library (say, one that came from npm and not the core library) have to be zone-aware to function correctly with zones? What does using zones mixed with libraries that aren't zone-aware look like? How much complexity does it add to the library to make it zone aware?
It monkey patches the entry points into javascript from the binding layer (some wrapping happens at a higher level), for the purpose of keeping track of the active zone. At that level we also wrap a try-catch block around all callbacks.
> Does a library (say, one that came from npm and not the core library) have to be zone-aware to function correctly with zones
It depends. Most modules shouldn't need any modification. However there are certain not-so-common cases (for example, when you're implementing a connection pool) that the module would need to be made zone-aware. It's necessary when the module wants to call a callback (or any function) in a child zone from a parent/ancestor zone.
Right now that's not very easy - you'd have to use a Gate (https://github.com/strongloop/zone#gates). W're working on an easier API.
I can see why it's doing it, actually, because the connection is presumably done at that point and an error after everything important is done is less important, but it's poorly explained at best (as being to prevent the 'zone from exploding').
However it could be that some data has already been sent back, in which case writeHead would throw. If that happens there isn't much more we can do.
What we're doing is make it unnecessary to add error handlers everywhere and still get caught by surprising failure modes. If the zone catches an error it cleans up (closes resources, cancel operations when that makes sense) and then routes the error to the zone's result callback so you can handle it in once place.
The 'status quo' is that node has domains, but zones should be conceptually cleaner and thus have less corner cases.
> one of them even has a null exception catch
I'm not sure what you mean here. The http demo catches an exception and prints the stack trace. We can do that because the zone cleans up the socket so it's not necessary to exit and restart node.