Merge pull request #15 from MattJin/master

merge

sections/errorhandling/catchunhandledpromiserejection.md

@@ -4,7 +4,7 @@
 
 ### One Paragraph Explainer
 
-Typically, most of modern Node.JS/Express application code runs within promises – whether within the .then handler, a function callback or in a catch block. Suprisingly, unless a developer remembered to add a .catch clause, errors thrown at these places are not handled  by the uncaughtException event-handler and disappear.  Recent versions of Node added a warning message when an unhandled rejection pops, though this might help to notice when things go wrong but it's obviously not a proper error handling method. The straightforward solution is to never forget adding .catch clauses within each promise chain call and redirect to a centralized error handler. However building your error handling strategy only on developer’s discipline is somewhat fragile. Consequently, it’s highly recommended using a graceful fallback and subscribe to `process.on(‘unhandledRejection’, callback)` – this will ensure that any promise error, if not handled locally, will get its treatment.
+Typically, most of modern Node.js/Express application code runs within promises – whether within the .then handler, a function callback or in a catch block. Suprisingly, unless a developer remembered to add a .catch clause, errors thrown at these places are not handled  by the uncaughtException event-handler and disappear.  Recent versions of Node added a warning message when an unhandled rejection pops, though this might help to notice when things go wrong but it's obviously not a proper error handling method. The straightforward solution is to never forget adding .catch clauses within each promise chain call and redirect to a centralized error handler. However building your error handling strategy only on developer’s discipline is somewhat fragile. Consequently, it’s highly recommended using a graceful fallback and subscribe to `process.on(‘unhandledRejection’, callback)` – this will ensure that any promise error, if not handled locally, will get its treatment.
 
 <br/><br/>
 

sections/errorhandling/centralizedhandling.md

@@ -65,19 +65,19 @@ app.use((err, req, res, next) => {
 ```
 
 ### Blog Quote: "Sometimes lower levels can’t do anything useful except propagate the error to their caller"
- From the blog Joyent, ranked 1 for the keywords “Node.JS error handling”
+ From the blog Joyent, ranked 1 for the keywords “Node.js error handling”
  
  > …You may end up handling the same error at several levels of the stack. This happens when lower levels can’t do anything useful except propagate the error to their caller, which propagates the error to its caller, and so on. Often, only the top-level caller knows what the appropriate response is, whether that’s to retry the operation, report an error to the user, or something else. But that doesn’t mean you should try to report all errors to a single top-level callback, because that callback itself can’t know in what context the error occurred…
 
  
 ### Blog Quote: "Handling each err individually would result in tremendous duplication"
- From the blog JS Recipes, ranked 17 for the keywords “Node.JS error handling”
+ From the blog JS Recipes, ranked 17 for the keywords “Node.js error handling”
  
  > ……In Hackathon Starter api.js controller alone, there are over 79 occurences of error objects. Handling each err individually would result in tremendous amount of code duplication. The next best thing you can do is to delegate all error handling logic to an Express middleware…
 
 
 ### Blog Quote: "HTTP errors have no place in your database code"
- From the blog Daily JS, ranked 14 for the keywords “Node.JS error handling”
+ From the blog Daily JS, ranked 14 for the keywords “Node.js error handling”
  
  > ……You should set useful properties in error objects, but use such properties consistently. And, don’t cross the streams: HTTP errors have no place in your database code. Or for browser developers, Ajax errors have a place in code that talks to the server, but not code that processes Mustache templates…
 

sections/errorhandling/documentingusingswagger.md

@@ -6,7 +6,7 @@
 REST APIs return results using HTTP status codes, it’s absolutely required for the API user to be aware not only about the API schema but also about potential errors – the caller may then catch an error and tactfully handle it. For example, your API documentation might state in advanced that HTTP status 409 is returned when the customer name already exist (assuming the API register new users) so the caller can correspondingly render the best UX for the given situation. Swagger is a standard that defines the schema of API documentation offering an eco-system of tools that allow creating documentation easily online, see print screens below
 
 ### Blog Quote: "You have to tell your callers what errors can happen"
-From the blog Joyent, ranked 1 for the keywords “Node.JS logging”
+From the blog Joyent, ranked 1 for the keywords “Node.js logging”
  
  > We’ve talked about how to handle errors, but when you’re writing a new function, how do you deliver errors to the code that called your function? …If you don’t know what errors can happen or don’t know what they mean, then your program cannot be correct except by accident. So if you’re writing a new function, you have to tell your callers what errors can happen and what they mean…
 

sections/errorhandling/operationalvsprogrammererror.md

@@ -27,18 +27,18 @@ throw new appError(errorManagement.commonErrors.InvalidInput, "Describe here wha
 ```
 
 ### Blog Quote: "Programmer errors are bugs in the program"
-From the blog Joyent, ranked 1 for the keywords “Node.JS error handling”
+From the blog Joyent, ranked 1 for the keywords “Node.js error handling”
  
  > …The best way to recover from programmer errors is to crash immediately. You should run your programs using a restarter that will automatically restart the program in the event of a crash. With a restarter in place, crashing is the fastest way to restore reliable service in the face of a transient programmer error…
 
 ### Blog Quote: "No safe way to leave without creating some undefined brittle state"
-From Node.JS official documentation
+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.  
 
 
 ### Blog Quote: "Otherwise you risk the state of your application"
-From the blog debugable.com, ranked 3 for the keywords “Node.JS uncaught exception”
+From the blog debugable.com, ranked 3 for the keywords “Node.js uncaught exception”
  
  > …So, unless you really know what you are doing, you should perform a graceful restart of your service after receiving an “uncaughtException” exception event. Otherwise you risk the state of your application, or that of 3rd party libraries to become inconsistent, leading to all kinds of crazy bugs…
 

sections/errorhandling/shuttingtheprocess.md

@@ -47,6 +47,6 @@ From the blog: JS Recipes
 
 
 ### Blog Quote: "No safe way to leave without creating some undefined brittle state"
-From Node.JS official documentation
+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.

sections/errorhandling/useonlythebuiltinerror.md

@@ -3,9 +3,9 @@
 
 ### One Paragraph Explainer
 
-The permissive nature of JS along with its variety code-flow options (e.g. EventEmitter, Callbacks, Promises, etc) pushes to great variance in how developers raise errors – some use strings, other define their own custom types. Using Node.JS built-in Error object helps to keep uniformity within your code and with 3rd party libraries, it also preserves significant information like the StackTrace. When raising the exception, it’s usually a good practice to fill it with additional contextual properties like the error name and the associated HTTP error code. To achieve this uniformity and practices, consider extending the Error object with additional properties, see code example below
+The permissive nature of JS along with its variety code-flow options (e.g. EventEmitter, Callbacks, Promises, etc) pushes to great variance in how developers raise errors – some use strings, other define their own custom types. Using Node.js built-in Error object helps to keep uniformity within your code and with 3rd party libraries, it also preserves significant information like the StackTrace. When raising the exception, it’s usually a good practice to fill it with additional contextual properties like the error name and the associated HTTP error code. To achieve this uniformity and practices, consider extending the Error object with additional properties, see code example below
 Blog Quote: “I don’t see the value in having lots of different types”
-From the blog Ben Nadel, ranked 5 for the keywords “Node.JS error object”
+From the blog Ben Nadel, ranked 5 for the keywords “Node.js error object”
 …”Personally, I don’t see the value in having lots of different types of error objects – JavaScript, as a language, doesn’t seem to cater to Constructor-based error-catching. As such, differentiating on an object property seems far easier than differentiating on a Constructor type…
 
 
@@ -61,7 +61,7 @@ if(user == null)
 
 
 ### Blog Quote: "A string is not an error"
-From the blog devthought.com, ranked 6 for the keywords “Node.JS error object”
+From the blog devthought.com, ranked 6 for the keywords “Node.js error object”
  
 > …passing a string instead of an error results in reduced interoperability between modules. It breaks contracts with APIs that might be performing instanceof Error checks, or that want to know more about the error. Error objects, as we’ll see, have very interesting properties in modern JavaScript engines besides holding the message passed to the constructor…  
 Blog Quote: “All JavaScript and System errors raised by Node.js inherit from Error”
@@ -72,6 +72,6 @@ From the blog machadogj
 > …One problem that I have with the Error class is that is not so simple to extend. Of course you can inherit the class and create your own Error classes like HttpError, DbError, etc. However that takes time, and doesn’t add too much value unless you are doing something with types. Sometimes, you just want to add a message, and keep the inner error, and sometimes you might want to extend the error with parameters, and such…
 
  ### Blog Quote: "All JavaScript and System errors raised by Node.js inherit from Error"
-From Node.JS official documentation
+From Node.js official documentation
  
 > …All JavaScript and System errors raised by Node.js inherit from, or are instances of, the standard JavaScript Error class and are guaranteed to provide at least the properties available on that class. A generic JavaScript Error object that does not denote any specific circumstance of why the error occurred. Error objects capture a “stack trace” detailing the point in the code at which the Error was instantiated, and may provide a text description of the error.All errors generated by Node.js, including all System and JavaScript errors, will either be instances of, or inherit from, the Error class…