diff --git a/sections/errorhandling/shuttingtheprocess.md b/sections/errorhandling/shuttingtheprocess.md
index c98773da..aac0aba1 100644
--- a/sections/errorhandling/shuttingtheprocess.md
+++ b/sections/errorhandling/shuttingtheprocess.md
@@ -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.
\ No newline at end of file
+> …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.