Update shuttingtheprocess.md

Fix indentation for errorHandler() and add missing closing bracket.
This commit is contained in:
Alejandro Corredor
2018-03-09 11:54:26 -05:00
committed by GitHub
parent ecf1fe9b3d
commit 37667105fe

View File

@ -19,15 +19,18 @@ process.on('uncaughtException', function(error) {
// centralized error handler encapsulates error-handling related logic
function errorHandler(){
function errorHandler() {
this.handleError = function (error) {
return logger.logError(err).then(sendMailToAdminIfCritical).then(saveInOpsQueueIfCritical).then(determineIfOperationalError);
}
return logger.logError(err)
.then(sendMailToAdminIfCritical)
.then(saveInOpsQueueIfCritical)
.then(determineIfOperationalError);
}
this.isTrustedError = function (error) {
return error.isOperational;
this.isTrustedError = function (error) {
return error.isOperational;
}
}
```
@ -49,4 +52,4 @@ From the blog: JS Recipes
### Blog Quote: "No safe way to leave without creating some undefined brittle state"
From Node.js official documentation
> …By the very nature of how throw works in JavaScript, there is almost never any way to safely “pick up where you 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, you might have many connections open, 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.
> …By the very nature of how throw works in JavaScript, there is almost never any way to safely “pick up where you 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, you might have many connections open, 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.