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

@@ -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

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.