My changes to the docs

docs/error_catchers.md

@@ -1,7 +1,11 @@
 # Error Catchers
 
-When Rocket wants to return an error page to the client, Rocket invokes the
-catcher for that error. A catcher is like a route, except it only handles
+When Rocket wants to return an error response type to the client,
+either because the request failed to pass any of the [request guards]
+(requests_request_guard.md) on the the handler's or because the matched 
+handler returned an `Err`, Rocket does this via error catchers.
+
+A catcher is like a route, except it only handles
 errors. Catchers are declared via the error attribute, which takes a single
 integer corresponding to the HTTP status code to catch. For instance, to
 declare a catcher for 404 errors, you’d write:

docs/requests_errors.md

@@ -1,8 +1,13 @@
 ## Errors
 Responders need not always generate a response. Instead, they can return an
 Err with a given status code. When this happens, Rocket forwards the request
-to the error catcher for the given status code. If none exists, which can
-only happen when using custom status codes, Rocket uses the 500 error catcher.
+to the [error catcher](error_catcher.md) for the given status code. Just like a
+request handler, an error catcher will return a response by returning any type 
+that has the `Responder` trait implemented. A common example would be to render
+a page displaying **400 Bad Request** to a user who sent a request with a 
+malformed json body. If no error_catcher is configured to handle an specific 
+http error code, which can only happen when using custom status codes, Rocket
+uses's the 500 error catcher.
 
 ### Result
 `Result` is one of the most commonly used responders. Returning a `Result` means