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 master 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:

    1. // XXX WARNING! BAD IDEA!
    3. const d = require('domain').create();
    4. d.on('error', (er) => {
    5.   // The error won't crash the process, but what it does is worse!
    6.   // Though we've prevented abrupt process restarting, we are leaking
    7.   // resources like crazy if this ever happens.
    8.   // This is no better than process.on('uncaughtException')!
    9.   console.log(`error, but oh well ${er.message}`);
    10. });
    11. d.run(() => {
    12.   require('http').createServer((req, res) => {
    13.     handleRequest(req, res);
    14.   }).listen(PORT);
    15. });

    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.

    1. // Much better!
    3. const cluster = require('cluster');
    4. const PORT = +process.env.PORT || 1337;
    6. if (cluster.isMaster) {
    7.   // A more realistic scenario would have more than 2 workers,
    8.   // and perhaps not put the master and worker in the same file.
    9.   //
    10.   // It is also possible to get a bit fancier about logging, and
    11.   // implement whatever custom logic is needed to prevent DoS
    12.   // attacks and other bad behavior.
    13.   //
    14.   // See the options in the cluster documentation.
    15.   //
    16.   // The important thing is that the master does very little,
    17.   // increasing our resilience to unexpected errors.
    19.   cluster.fork();
    20.   cluster.fork();
    22.   cluster.on('disconnect', (worker) => {
    23.     console.error('disconnect!');
    24.     cluster.fork();
    25.   });
    27. } else {
    28.   // the worker
    29.   //
    30.   // This is where we put our bugs!
    32.   const domain = require('domain');
    34.   // See the cluster documentation for more details about using
    35.   // worker processes to serve requests. How it works, caveats, etc.
    37.   const server = require('http').createServer((req, res) => {
    38.     const d = domain.create();
    39.     d.on('error', (er) => {
    40.       console.error(`error ${er.stack}`);
    42.       // We're in dangerous territory!
    43.       // By definition, something unexpected occurred,
    44.       // which we probably didn't want.
    45.       // Anything can happen now! Be very careful!
    47.       try {
    48.         // Make sure we close down within 30 seconds
    49.         const killtimer = setTimeout(() => {
    50.           process.exit(1);
    51.         }, 30000);
    52.         // But don't keep the process open just for that!
    53.         killtimer.unref();
    55.         // Stop taking new requests.
    56.         server.close();
    58.         // Let the master know we're dead. This will trigger a
    59.         // 'disconnect' in the cluster master, and then it will fork
    60.         // a new worker.
    61.         cluster.worker.disconnect();
    63.         // Try to send an error to the request that triggered the problem
    64.         res.statusCode = 500;
    65.         res.setHeader('content-type', 'text/plain');
    66.         res.end('Oops, there was a problem!\n');
    67.       } catch (er2) {
    68.         // Oh well, not much we can do at this point.
    69.         console.error(`Error sending 500! ${er2.stack}`);
    70.       }
    71.     });
    73.     // Because req and res were created before this domain existed,
    74.     // we need to explicitly add them.
    75.     // See the explanation of implicit vs explicit binding below.
    76.     d.add(req);
    77.     d.add(res);
    79.     // Now run the handler function in the domain.
    80.     d.run(() => {
    81.       handleRequest(req, res);
    82.     });
    83.   });
    84.   server.listen(PORT);
    85. }
    87. // This part is not important. Just an example routing thing.
    88. // Put fancy application logic here.
    89. function handleRequest(req, res) {
    90.   switch (req.url) {
    91.     case '/error':
    92.       // We do some async stuff, and then...
    93.       setTimeout(() => {
    94.         // Whoops!
    95.         flerb.bark();
    96.       }, timeout);
    97.       break;
    98.     default:
    99.       res.end('ok');
    100.   }
    101. }