Earlier 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…
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…
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.