Hacker News Reader

Comment by piscisaureus | Hacker News Reader

> I'm having a really hard time seeing how this is an actual improvement on the status quo

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.

View on HN

The comparison page highlights that Zone.js is better than promises because of long stack traces [1], but most promise implementations already have that [2]. I'm confused, that seems to be the only comparison to promises.

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

Note that the comparison page doesn't have the "zone" library we just announced on it. Zone.js is conceptually a bit different and it targets browsers.

So, looking at the examples again and going back to this:

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

> I'm really unclear on how the zone library is doing the magical interception of errors

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.

https://github.com/strongloop/zone/blob/master/showcase/long... <- this is the line I was referring to.

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

When control reaches there we know something went wrong within the zone that's sending the response, so it's nice to send a HTTP 500 error back.

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.

Reply on news.ycombinator.com