Domain
目录
历史
版本 | 历史变更 |
---|---|
v8.8.0 | Any `Promise`s created in VM contexts no longer have a `.domain` property. Their handlers are still executed in the proper domain, however, and `Promise`s created in the main context still possess a `.domain` property. |
v8.0.0 | Handlers for `Promise`s are now invoked in the domain in which the first promise of a chain was created. |
v1.4.2 | 自 v1.4.2 版本开始新增 |
自 v0.10.0 版本开始新增
源代码: lib/domain.js
This module is pending deprecation. Once a replacement API has been finalized, this module will be fully deprecated. Most developers should not have cause to use this module. Users who absolutely must have the functionality that domains provide may rely on it for the time being but should expect to have to migrate to a different solution in the future.
Domains provide a way to handle multiple different IO operations as a
single group. If any of the event emitters or callbacks registered to a
domain emit an 'error'
event, or throw an error, then the domain object
will be notified, rather than losing the context of the error in the
process.on('uncaughtException')
handler, or causing the program to
exit immediately with an error code.
Warning: Don't ignore errors!
Domain error handlers are not a substitute for closing down a process when an error occurs.
By the very nature of how throw
works in JavaScript, there is almost
never any way to safely "pick up where it left off", without leaking
references, or creating some other sort of undefined brittle state.
The safest way to respond to a thrown error is to shut down the process. Of course, in a normal web server, there may be many open connections, and it is not reasonable to abruptly shut those down because an error was triggered by someone else.
The better approach is to send an error response to the request that triggered the error, while letting the others finish in their normal time, and stop listening for new requests in that worker.
In this way, domain
usage goes hand-in-hand with the cluster module,
since the primary process can fork a new worker when a worker
encounters an error. For Node.js programs that scale to multiple
machines, the terminating proxy or service registry can take note of
the failure, and react accordingly.
For example, this is not a good idea:
JS
By using the context of a domain, and the resilience of separating our program into multiple worker processes, we can react more appropriately, and handle errors with much greater safety.
JS
Additions to Error
objects
Any time an Error
object is routed through a domain, a few extra fields
are added to it.
error.domain
The domain that first handled the error.error.domainEmitter
The event emitter that emitted an'error'
event with the error object.error.domainBound
The callback function which was bound to the domain, and passed an error as its first argument.error.domainThrown
A boolean indicating whether the error was thrown, emitted, or passed to a bound callback function.
Implicit binding
If domains are in use, then all new EventEmitter
objects (including
Stream objects, requests, responses, etc.) will be implicitly bound to
the active domain at the time of their creation.
Additionally, callbacks passed to lowlevel event loop requests (such as
to fs.open()
, or other callback-taking methods) will automatically be
bound to the active domain. If they throw, then the domain will catch
the error.
In order to prevent excessive memory usage, Domain
objects themselves
are not implicitly added as children of the active domain. If they
were, then it would be too easy to prevent request and response objects
from being properly garbage collected.
To nest Domain
objects as children of a parent Domain
they must be
explicitly added.
Implicit binding routes thrown errors and 'error'
events to the
Domain
's 'error'
event, but does not register the EventEmitter
on the
Domain
.
Implicit binding only takes care of thrown errors and 'error'
events.
Explicit binding
Sometimes, the domain in use is not the one that ought to be used for a specific event emitter. Or, the event emitter could have been created in the context of one domain, but ought to instead be bound to some other domain.
For example, there could be one domain in use for an HTTP server, but perhaps we would like to have a separate domain to use for each request.
That is possible via explicit binding.
JS
M domain.create()
- Returns:
Domain
C Domain
- Extends:
EventEmitter
The Domain
class encapsulates the functionality of routing errors and
uncaught exceptions to the active Domain
object.
To handle the errors that it catches, listen to its 'error'
event.
M domain.members
An array of timers and event emitters that have been explicitly added to the domain.
M domain.add(emitter)
emitter
EventEmitter
|Timer
emitter or timer to be added to the domain
Explicitly adds an emitter to the domain. If any event handlers called by
the emitter throw an error, or if the emitter emits an 'error'
event, it
will be routed to the domain's 'error'
event, just like with implicit
binding.
This also works with timers that are returned from setInterval()
and
setTimeout()
. If their callback function throws, it will be caught by
the domain 'error'
handler.
If the Timer or EventEmitter
was already bound to a domain, it is removed
from that one, and bound to this one instead.
M domain.bind(callback)
The returned function will be a wrapper around the supplied callback
function. When the returned function is called, any errors that are
thrown will be routed to the domain's 'error'
event.
JS
M domain.enter()
The enter()
method is plumbing used by the run()
, bind()
, and
intercept()
methods to set the active domain. It sets domain.active
and
process.domain
to the domain, and implicitly pushes the domain onto the domain
stack managed by the domain module (see domain.exit()
for details on the
domain stack). The call to enter()
delimits the beginning of a chain of
asynchronous calls and I/O operations bound to a domain.
Calling enter()
changes only the active domain, and does not alter the domain
itself. enter()
and exit()
can be called an arbitrary number of times on a
single domain.
M domain.exit()
The exit()
method exits the current domain, popping it off the domain stack.
Any time execution is going to switch to the context of a different chain of
asynchronous calls, it's important to ensure that the current domain is exited.
The call to exit()
delimits either the end of or an interruption to the chain
of asynchronous calls and I/O operations bound to a domain.
If there are multiple, nested domains bound to the current execution context,
exit()
will exit any domains nested within this domain.
Calling exit()
changes only the active domain, and does not alter the domain
itself. enter()
and exit()
can be called an arbitrary number of times on a
single domain.
M domain.intercept(callback)
This method is almost identical to domain.bind(callback)
. However, in
addition to catching thrown errors, it will also intercept Error
objects sent as the first argument to the function.
In this way, the common if (err) return callback(err);
pattern can be replaced
with a single error handler in a single place.
JS
M domain.remove(emitter)
emitter
EventEmitter
|Timer
emitter or timer to be removed from the domain
The opposite of domain.add(emitter)
. Removes domain handling from the
specified emitter.
M domain.run(fn[, ...args])
Run the supplied function in the context of the domain, implicitly binding all event emitters, timers, and lowlevel requests that are created in that context. Optionally, arguments can be passed to the function.
This is the most basic way to use a domain.
JS
In this example, the d.on('error')
handler will be triggered, rather
than crashing the program.
Domains and promises
As of Node.js 8.0.0, the handlers of promises are run inside the domain in
which the call to .then()
or .catch()
itself was made:
JS
A callback may be bound to a specific domain using domain.bind(callback)
:
JS
Domains will not interfere with the error handling mechanisms for
promises. In other words, no 'error'
event will be emitted for unhandled
Promise
rejections.