Correct grammar and translations for the "Error Handling" section of

11.1

en/eBook/11.1.md

@@ -116,9 +116,7 @@ Using type assertion, we can check whether or not our error is of type net.Error
 
 ## Error handling
 
-Go in the error handling on the use of the C check the return value similar manner , rather than most other mainstream languages used in unexpected ways , which caused a code written on a big disadvantage : error handling code redundancy , for this kind of situation is that we detect function to reduce reuse similar code .
-
-Look at the following example code:
+Go handles errors and checks the return values of functions in a C-like fashion, which is different than what most of the other major languages do. This makes the code more explicit and predictable, but also more verbose. To reduce the redundancy of our error-handling code, we can use abstract error handling functions that allow us to implement similar error handling behaviour: 
 
     func init() {
 		http.HandleFunc("/view", viewRecord)
@@ -137,7 +135,9 @@ Look at the following example code:
 		}
 	}
 
-The above example shows a template to get data and call has detected an error when an error occurs , call a unified processing function `http.Error`, returned to the client 500 error code and display the corresponding error data . But when more and more HandleFunc joined, so that error-handling logic code will be more and more, in fact, we can customize the router to reduce the code ( realization of the ideas you can refer to Chapter III of the HTTP Detailed ) .
+The above example demonstrate access to data and template call has detected error when an error occurs , call a unified handler http.Error, returns a 500 error code to the client , and display the corresponding error data. But when more and more HandleFunc join, so error-handling logic code will be more and more, in fact, we can customize the router to reduce code ( refer to realize the idea of ​​the third chapter of HTTP Detailed) .
+
+The above function is an example of getting data and handling an error when it occurs by calling a unified error processing function called `http.Error`. In this case, it will return  an Internal Error 500 code to the client, and display the corresponding error data. Even using this method however, when more and more `HandleFunc`'s are needed, the error-handling logic can still become quite bloated. An alternative approach would be to customize our router to handle errors by default:
 
     type appHandler func(http.ResponseWriter, *http.Request) error
 
@@ -147,13 +147,13 @@ The above example shows a template to get data and call has detected an error wh
 		}
 	}
 
-Above we defined a custom router , and then we can adopt the following approach to registration function :
+Above we've defined a custom router. We can then register our handler as usual:
 
     func init() {
 		http.Handle("/view", appHandler(viewRecord))
 	}
 
-When requested `/view` when we can become as logical processing code, and the first implementation has been compared to a lot simpler .
+The `/view` handler can then be handled by the following code; it is a lot simpler than our original implementation isn't it? 
 
     func viewRecord(w http.ResponseWriter, r *http.Request) error {
 		c := appengine.NewContext(r)
@@ -165,7 +165,7 @@ When requested `/view` when we can become as logical processing code, and the fi
 		return viewTemplate.Execute(w, record)
 	}
 
-The above example error handling when all errors are returned to the user 500 error code, and then print out the corresponding error code , in fact, we can put this definition more friendly error messages when debugging is also convenient positioning problem, we can custom return types of errors :
+The error handler example above will return the 500 Internal Error code to users when any errors occur, in addition to printing out the corresponding error code. In fact, we can customize the type of error returned to output a more developer friendly error message with information that is useful for debugging like so:  
 
     type appError struct {
 		Error   error
@@ -173,7 +173,7 @@ The above example error handling when all errors are returned to the user 500 er
 		Code    int
 	}
 
-So that our custom router can be changed as follows :
+Our custom router can be changed accordingly:
 
     type appHandler func(http.ResponseWriter, *http.Request) *appError
 
@@ -185,7 +185,7 @@ So that our custom router can be changed as follows :
 		}
 	}
 
-Such custom error after modifying our logic can be changed as follows :
+After we've finished modifying our custom error, our logic can be changed as follows:
 
     func viewRecord(w http.ResponseWriter, r *http.Request) *appError {
 		c := appengine.NewContext(r)
@@ -200,7 +200,9 @@ Such custom error after modifying our logic can be changed as follows :
 		return nil
 	}
 
-As shown above, in our view when you can visit according to different situations for different error codes and error messages , although this first version of the code and the amount is almost, but this show is more obvious error , the error message prompts more friendly , scalability is also better than the first one .
+As shown above, in view of the time we can get access to different error codes and error messages depending on the case, although this version of our code is a little bit similar to the previous one, it's more explicit error, the error message prompts more friendly , scalability is also better than the first one .
+
+As shown above, we can return different error codes and error messages in our views, depending on the situation. Although this version of our code functions similarly to the previous version, it's more explicit, and its error message prompts are more comprehensible. All of these factors can help to make your application more scalable when complexity increases.     
 
 ## Summary