Zone class abstract final

A zone represents an environment that remains stable across asynchronous calls.

All code is executed in the context of a zone, available to the code as Zone.current. The initial main function runs in the context of the default zone (Zone.root). Code can be run in a different zone using either runZoned or runZonedGuarded to create a new zone and run code in it, or Zone.run to run code in the context of an existing zone which may have been created earlier using Zone.fork.

Developers can create a new zone that overrides some of the functionality of an existing zone. For example, custom zones can replace or modify the behavior of print, timers, microtasks or how uncaught errors are handled.

The Zone class is not subclassable, but users can provide custom zones by forking an existing zone (usually Zone.current) with a ZoneSpecification. This is similar to creating a new class that extends the base Zone class and that overrides some methods, except without actually creating a new class. Instead the overriding methods are provided as functions that explicitly take the equivalent of their own class, the "super" class and the this object as parameters.

Asynchronous callbacks always run in the context of the zone where they were scheduled. This is implemented using two steps:

1. the callback is first registered using one of registerCallback, registerUnaryCallback, or registerBinaryCallback. This allows the zone to record that a callback exists and potentially modify it (by returning a different callback). The code doing the registration (e.g., Future.then) also remembers the current zone so that it can later run the callback in that zone.
2. At a later point the registered callback is run in the remembered zone, using one of run, runUnary or runBinary.

This is all handled internally by the platform code and most users don't need to worry about it. However, developers of new asynchronous operations, provided by the underlying system, must follow the protocol to be zone compatible.

For convenience, zones provide bindCallback (and the corresponding bindUnaryCallback and bindBinaryCallback) to make it easier to respect the zone contract: these functions first invoke the corresponding register functions and then wrap the returned function so that it runs in the current zone when it is later asynchronously invoked.

Similarly, zones provide bindCallbackGuarded (and the corresponding bindUnaryCallbackGuarded and bindBinaryCallbackGuarded), when the callback should be invoked through Zone.runGuarded.