add some things to the error and logging articles

_posts/blog/2020-12-09-guide-on-error-handling.md

@@ -28,7 +28,7 @@ Please read through the comments as they explain how errors should be treated.
     // This can be any type of action that might fail
     Database.connect().insert({ value: 'Some information' })
   } catch (err) {
-    // Is important to **log these** errors with highest priority (error)
+    // It's important to **log these** errors with highest priority (error)
     logger.error('Error happened while trying to insert some information', err) // Error context is passed here
 
     // Should the script continue?
@@ -36,7 +36,7 @@ Please read through the comments as they explain how errors should be treated.
   }
 ```
 
-It is necessary to pass the error context to the logger so the error can be traced later.
+It is necessary to pass the error along with context information, that will help to trace and resolve the issue.
 
 ### Back-end application - Responding to client requests
 
@@ -57,11 +57,11 @@ This is usually how web applications are built and the most common scenario wher
         res.status(400).json({
           message: `Invalid input. ${err.message}`
         })
-      else if (err instanceof RecoverableError) {
+      } else if (err instanceof RecoverableError) {
         // As a `RecovarableError` we can think of an error that most usually doesn't happen
         // but can and we have a way to continue the rest of the process and handle the error recovery later.
         // As an example we can imagine a case of sending an email to users with some information.
-        logger.error('Error while sending mail', err)
+        logger.error('Error while sending mail', err, { message, author })
 
         // Sending an email is not a crucial part of the functionality and can be done later.
         // So we continue the functionality but we log the error so we know that we have to handle it. 
@@ -75,7 +75,7 @@ This is usually how web applications are built and the most common scenario wher
 
         // In this case we want to `log` this error with full context,
         // so it can be found and fixed if it is a programmer's fault.
-        logger.error('Unexpected error happened', err)
+        logger.error('Unexpected error happened', err, { message, author })
 
         // Client should be informed of such an error but without the context, as it might reveal proprietary information about the system
         res.status(500).json({
@@ -150,7 +150,7 @@ If you use an external error monitoring tool like [Sentry](https://sentry.io/wel
 
 ## Rules
 
-To summarize this we can create a list of rules:
+To summarize this, we can create a list of rules:
 
 - Error messages have to be informative for the client, but they **can't reveal private and proprietary information** about the system architecture
 - Errors should be logged only when they require additional action

_posts/blog/2020-12-18-logging-recommendations.md

@@ -48,7 +48,7 @@ _Verbose logs might be useful for staging environments where you want to see mor
 It is very important to log all the information required for developers and DevOps to retrieve as much valuable information from the logs as possible.
 
 Messages are usually generated in a way where developers don't have to add things like timestamps, log levels, etc., and repeat themselves.
-Timestamps and log levels are attached to the messages that are logged automatically.
+Timestamps and log levels are attached to the messages automatically.
 
 #### Errors
 
@@ -88,7 +88,7 @@ Developers should **not** expose the functionality to users.
 
 There is an _npm package_ [debug](https://www.npmjs.com/package/debug) that
 enables developers to write debug logs that persist in the codebase.
-To reveal the logs in the console they have to be enabled.
+To reveal the logs in the console, they have to be enabled.
 
 There are 3rd party **error monitoring** services, that can help us collect information from errors that occur in different parts of the application.