From 39e1a5a380aa2bbc4e2d164e8e4bf37cfd512516 Mon Sep 17 00:00:00 2001
From: Hridayesh Sharma <vyasriday7@gmail.com>
Date: Tue, 25 Aug 2020 03:05:27 +0530
Subject: [PATCH] fixed multiple grammatical errors in docs. (#1497)

* fixed grammatical errors in faq docs

* fixed grammatical and style issues in error handling docs

* fixed grammatical issues in guide

* fixed grammatical error in error handling docs

* Updated middleware to use plural form to be middleware instead of
middlewares
---
 docs/error-handling.md | 10 +++++-----
 docs/guide.md          | 20 +++++++++++---------
 2 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/docs/error-handling.md b/docs/error-handling.md
index 35a8e905e..cb30c20be 100644
--- a/docs/error-handling.md
+++ b/docs/error-handling.md
@@ -2,7 +2,7 @@
 
 ## Try-Catch
 
-  Using async functions means that you can try-catch `next`.
+  Using async functions mean that you can try-catch `next`.
   This example adds a `.status` to all errors:
 
   ```js
@@ -18,9 +18,9 @@
 
 ### Default Error Handler
 
-  The default error handler is essentially a try-catch at
+  The default error handler is essentially a `try-catch` at
   the very beginning of the middleware chain. To use a
-  different error handler, simply put another try-catch at
+  different error handler, simply put another `try-catch` at
   the beginning of the middleware chain, and handle the error
   there. However, the default error handler is good enough for
   most use cases. It will use a status code of `err.status`,
@@ -29,7 +29,7 @@
   error code will be used (e.g. for the code 500 the message
   "Internal Server Error" will be used). All headers will be
   cleared from the request, but any headers in `err.headers`
-  will then be set. You can use a try-catch, as specified
+  will then be set. You can use a `try-catch`, as specified
   above, to add a header to this list.
 
   Here is an example of creating your own error handler:
@@ -52,7 +52,7 @@ app.use(async (ctx, next) => {
 
   Error event listeners can be specified with `app.on('error')`.
   If no error listener is specified, a default error listener
-  is used. Error listener receive all errors that make their
+  is used. Error listeners receive all errors that make their
   way back through the middleware chain, if an error is caught
   and not thrown again, it will not be passed to the error
   listener. If no error event listener is specified, then
diff --git a/docs/guide.md b/docs/guide.md
index 77c0a6f7f..4bbb8ff60 100644
--- a/docs/guide.md
+++ b/docs/guide.md
@@ -5,14 +5,16 @@
 
 ## Table of Contents
 
-- [Writing Middleware](#writing-middleware)
-- [Middleware Best Practices](#middleware-best-practices)
-  - [Middleware options](#middleware-options)
-  - [Named middleware](#named-middleware)
-  - [Combining multiple middleware with koa-compose](#combining-multiple-middleware-with-koa-compose)
-  - [Response Middleware](#response-middleware)
-- [Async operations](#async-operations)
-- [Debugging Koa](#debugging-koa)
+- [Guide](#guide)
+  - [Table of Contents](#table-of-contents)
+  - [Writing Middleware](#writing-middleware)
+  - [Middleware Best Practices](#middleware-best-practices)
+    - [Middleware options](#middleware-options)
+    - [Named middleware](#named-middleware)
+    - [Combining multiple middleware with koa-compose](#combining-multiple-middleware-with-koa-compose)
+    - [Response Middleware](#response-middleware)
+  - [Async operations](#async-operations)
+  - [Debugging Koa](#debugging-koa)
 
 ## Writing Middleware
 
@@ -59,7 +61,7 @@ app.use(responseTime);
 
 ### Middleware options
 
-  When creating public middleware it's useful to conform to the convention of
+  When creating a public middleware, it's useful to conform to the convention of
   wrapping the middleware in a function that accepts options, allowing users to
   extend functionality. Even if your middleware accepts _no_ options, this is still
   a good idea to keep things uniform.