Italian Translation Report: Node.js [Part 27 - 1056 words]

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:
XXX WARNING! BAD IDEA!
The error won't crash the process, but what it does is worse!
Though we've prevented abrupt process restarting, we are leaking resources like crazy if this ever happens.
This is no better than
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.
Much better!
A more realistic scenario would have more than 2 workers, and perhaps not put the master and worker in the same file.
It is also possible to get a bit fancier about logging, and implement whatever custom logic is needed to prevent DoS attacks and other bad behavior.
See the options in the cluster documentation.
The important thing is that the master does very little, increasing our resilience to unexpected errors.
This is where we put our bugs!
See the cluster documentation for more details about using worker processes to serve requests.
How it works, caveats, etc.
Note: We're in dangerous territory!
By definition, something unexpected occurred, which we probably didn't want.
Anything can happen now! Be very careful!
make sure we close down within 30 seconds
But don't keep the process open just for that!
stop taking new requests.
Let the master know we're dead.
This will trigger a in the cluster master, and then it will fork a new worker.
try to send an error to the request that triggered the problem
oh well, not much we can do at this point.
Because req and res were created before this domain existed, we need to explicitly add them.
See the explanation of implicit vs explicit binding below.
Now run the handler function in the domain.
This part is not important.
Just an example routing thing.
Put fancy application logic here.
We do some async stuff, and then...
Additions to Error objects
Any time an object is routed through a domain, a few extra fields are added to it.
The domain that first handled the error.
The event emitter that emitted an event with the error object.
The callback function which was bound to the domain, and passed an error as its first argument.
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 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, 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, 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 objects as children of a parent they must be explicitly added.
Implicit binding routes thrown errors and events to the event, but does not register the on the
Implicit binding only takes care of thrown errors and 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.
create a top-level domain for the server
server is created in the scope of
however, we'd prefer to have a separate domain for each request.
create it first thing, and add and to it.
The class encapsulates the functionality of routing errors and uncaught exceptions to the active object.
is a child class of
To handle the errors that it catches, listen to its event.
An array of timers and event emitters that have been explicitly added to the domain.
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 event, it will be routed to the domain's event, just like with implicit binding.
This also works with timers that are returned from and
If their callback function throws, it will be caught by the domain handler.
If the Timer or was already bound to a domain, it is removed from that one, and bound to this one instead.
The callback function
The bound function
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 event.
if this throws, it will also be passed to the domain
an error occurred somewhere.
if we throw it now, it will crash the program with the normal line number and stack message.
The method is plumbing used by the and methods to set the active domain.
It sets and to the domain, and implicitly pushes the domain onto the domain stack managed by the domain module (see for details on the domain stack).
The call to delimits the beginning of a chain of asynchronous calls and I/O operations bound to a domain.
Calling changes only the active domain, and does not alter the domain itself.
and can be called an arbitrary number of times on a single domain.
The 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 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, will exit any domains nested within this domain.
The callback function
The intercepted function
This method is almost identical to
However, in addition to catching thrown errors, it will also intercept objects sent as the first argument to the function.
In this way, the common pattern can be replaced with a single error handler in a single place.
note, the first argument is never passed to the callback since it is assumed to be the 'Error' argument and thus intercepted by the domain.
if this throws, it will also be passed to the domain so the error-handling logic can be moved to the 'error' event on the domain instead of being repeated throughout the program.
an error occurred somewhere.
if we throw it now, it will crash the program with the normal line number and stack message.
emitter or timer to be removed from the domain
The opposite of
Removes domain handling from the specified emitter.
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.
In this example, the 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 or itself was made:
A callback may be bound to a specific domain using
Note that domains will not interfere with the error handling mechanisms for Promises, i.e. no event will be emitted for unhandled rejections.