[spankalee]

The article only covered error handling, but Zones are a lot more powerful than that. They are nestable (forkable), they can store arbitrary values, intercept microtasks, timers, wrap closures to be associated with the Zone, and a few more things.

Then the key part in Dart is that all of the APIs that invoke callbacks based on external events run the callbacks in the Zone they were registered in. This is what allows Zones to be used to easily run code at the beginning or end of every event loop turn.

[eldude]

> They are nestable

trycatch is nestable as well.

> they can store arbitrary values, timers

Nice. I am currently decoupling trycatch's hooking layer to allow for this arbitrarily[1]. The continuation-local-storage library[2] allows for this functionality as well.

> intercept microtasks

Care to elaborate?

> wrap closures to be associated with the Zone

Yup, similar to domains, though I do wonder when this is necessary? One use case that came up with trycatch was finally support, or the need to exit the current domain/trycatch context.[3]

Lastly, there's one consistent failure I see in all these domain-like, async listener-like, long-stack-trace, event-source modules and that's long-lived resources or how they incorrectly handle EventEmitter handler's context[4], with the core issue being the boundary at which the hook is applied (From Trevor Norris' comment):

    After thinking this over, it occurred to me that trycatch is a top down approach. Whereas AsyncListener is bottom up.

Long story short, things like keep-alive sockets will retain a domain/context/zone(?) and their handlers will be called with the incorrect context.

Do you fix this in your zone.js implementation?

[1] https://github.com/CrabDude/trycatch/issues/38

[2] https://github.com/othiym23/node-continuation-local-storage

[3] https://github.com/CrabDude/trycatch/issues/37

[4] https://github.com/CrabDude/trycatch/issues/32

[spankalee]

>> They are nestable > trycatch is nestable as well.

By nestable I mean that you can fork a Zone, configure different values and handlers (for things like intercepting microtasks and timers), and run some code in the forked Zone. All async callbacks spawned from that code will run in the forked Zone.

>> intercept microtasks > Care to elaborate?

Dart has an API for scheduling microtasks inside the event loop: scheduleMicrotask(callback). Zones can intercept this call to do things like keep track of the size of the queue and do something when it empties, or manually and synchronously execute the tasks for controlling time in tests.

>> wrap closures to be associated with the Zone > Yup, similar to domains, though I do wonder when this is necessary?

It's useful for interacting with external systems and preserving Zone affinity. This is how dart:html ensures that event subscription callbacks are run in the correct Zone, it wraps callbacks (only if necessary - if there's an installed Zone) in the Zone and then hands them to the browser. The wrapper installs the correct Zone before executing the callback.

> Long story short, things like keep-alive sockets will retain a domain/context/zone(?) and their handlers will be called with the incorrect context. > > Do you fix this in your zone.js implementation?

Zone.js is a port of Dart's Zone, so I don't know how faithfully it reproduces it. In Dart, I don't know of any API that doesn't execute callbacks in the correct Zone, except for a bug in dart:js that's being worked on.