Zones – Robust error handling and flow control for Node.js
1–10 of 22 posts
Re: Zones – Robust error handling and flow control for Node.js
#2> We’re waiting eagerly for node v0.12 to be released.
> Unfortunately, the release may not happen soon since there are about 800 open bugs and about 180 pull requests waiting to be reviewed.
Is it a real problem? Seems that other popular projects like Ruby on Rails have a similar number of opened issues and it's not stopping them from releasing new versions.
Does the Node core team have any plans how to prevent this situation in the future?
Re: Zones – Robust error handling and flow control for Node.js
#3I'm having a really hard time seeing how this is an actual improvement on the status quo. It just seems to build up a lot of complexity and create new and more confusing corner cases. I have a hard time following the demos, even with copious comments, and one of them even has a null exception catch and calls it a good thing (the http long stack demo).
Re: Zones – Robust error handling and flow control for Node.js
#4I'm having a really hard time seeing how this is an actual improvement on the status quo. It just seems to build up a lot of complexity and create new and more confusing corner cases. I have a hard time following the demos, even with copious comments, and one of them even has a null exception catch and calls it a good thing (the http long stack demo).
> 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.
Re: Zones – Robust error handling and flow control for Node.js
#5I'm having a really hard time seeing how this is an actual improvement on the status quo. It just seems to build up a lot of complexity and create new and more confusing corner cases. I have a hard time following the demos, even with copious comments, and one of them even has a null exception catch and calls it a good thing (the http long stack demo).
> 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…
https://github.com/strongloop/zone/blob/master/showcase/long... 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').
Re: Zones – Robust error handling and flow control for Node.js
#6Earlier quoted context omitted.
> 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…
https://github.com/strongloop/zone/blob/master/showcase/long... 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.
Re: Zones – Robust error handling and flow control for Node.js
#7I'm having a really hard time seeing how this is an actual improvement on the status quo. It just seems to build up a lot of complexity and create new and more confusing corner cases. I have a hard time following the demos, even with copious comments, and one of them even has a null exception catch and calls it a good thing (the http long stack demo).
> 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…
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?
Re: Zones – Robust error handling and flow control for Node.js
#8I'm having a really hard time seeing how this is an actual improvement on the status quo. It just seems to build up a lot of complexity and create new and more confusing corner cases. I have a hard time following the demos, even with copious comments, and one of them even has a null exception catch and calls it a good thing (the http long stack demo).
> 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…
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
Re: Zones – Robust error handling and flow control for Node.js
#9I highly recommend listening to JavaScript Jabber's Zone.js interview [1] with Brian Ford that came out yesterday. He mentions collaborating with this NodeJS Zones project and the possibility of convergence.
I also recommend watching his ng-conf talk [2] on Zone.js to get a better understanding of what zones enable.
[1] http://javascriptjabber.com/110-jsj-zones-with-brian-ford/
Re: Zones – Robust error handling and flow control for Node.js
#10> We’re waiting eagerly for node v0.12 to be released. > Unfortunately, the release may not happen soon since there are about 800 open bugs and about 180 pull requests waiting to be reviewed. Is it a real problem? Seems that other popular projects like Ruby on Rails have a similar number of opened issues and it's not stopping them from releasing new versions. Does the Node core team have any plans how to prevent this…
That quote and those numbers are incredibly misleading, I'm not sure why they use that to prove Node 0.12 isn't coming soon. If you actually look at the issues on Github, only around 30 of those are marked as 0.12, with the rest being various other milestones including 0.13 and 1.0. It has also already been stated that there is only one more 0.11 release before 0.12.