javascript-tutorial · iliakan · Mar 3, 2018 · Feb 5, 2018
diff --git a/1-js/08-error-handling/1-try-catch/article.md b/1-js/08-error-handling/1-try-catch/article.md
@@ -81,7 +81,7 @@ Let's see more examples.
 ````warn header="`try..catch` only works for runtime errors"
 For `try..catch` to work, the code must be runnable. In other words, it should be valid JavaScript.
 
-It won't work if the code is syntactically wrong, for instance it has unmatched figure brackets:
+It won't work if the code is syntactically wrong, for instance it has unmatched curly braces:
 
 ```js run
 try {
@@ -98,7 +98,7 @@ So, `try..catch` can only handle errors that occur in the valid code. Such error
 
 
 ````warn header="`try..catch` works synchronously"
-If an exception happens in a "scheduled" code, like in `setTimeout`, then `try..catch` won't catch it:
+If an exception happens in "scheduled" code, like in `setTimeout`, then `try..catch` won't catch it:
 
 ```js run
 try {
@@ -110,7 +110,7 @@ try {
 }
 ```
 
-That's because `try..catch` actually wraps the `setTimeout` call that schedules the function. But the function itself is executed later, when the engine has already have left the `try..catch` construct.
+That's because `try..catch` actually wraps the `setTimeout` call that schedules the function. But the function itself is executed later, when the engine has already left the `try..catch` construct.
 
 To catch an exception inside a scheduled function, `try..catch` must be inside that function:
 ```js run
@@ -172,9 +172,9 @@ try {
 
 Let's explore a real-life use case of `try..catch`.
 
-As we already know, JavaScript supports method [JSON.parse(str)](mdn:js/JSON/parse) to read JSON-encoded values.
+As we already know, JavaScript supports the [JSON.parse(str)](mdn:js/JSON/parse) method to read JSON-encoded values.
 
-Usually it's used to decode the data received over the network, from the server or another source.
+Usually it's used to decode data received over the network, from the server or another source.
 
 We receive it and call `JSON.parse`, like this:
 
@@ -190,13 +190,13 @@ alert( user.name ); // John
 alert( user.age );  // 30
 ```
 
-More detailed information about JSON you can find in the chapter <info:json>.
+You can find more detailed information about JSON in the <info:json> chapter.
 
 **If `json` is malformed, `JSON.parse` generates an error, so the script "dies".**
 
 Should we be satisfied with that? Of course, not!
 
-This way if something's wrong with the data, the visitor will never know that (unless he opens developer console). And people really really don't like when something "just dies" without any error message.
+This way, if something's wrong with the data, the visitor will never know that (unless he opens developer console). And people really don't like when something "just dies" without any error message.
 
 Let's use `try..catch` to handle the error:
 
@@ -220,11 +220,11 @@ try {
 }
 ```
 
-Here we use `catch` block only to show the message, but we can do much more: a new network request, suggest an alternative to the visitor, send the information about the error to a logging facility... All much better than just dying.
+Here we use the `catch` block only to show the message, but we can do much more: send a new network request, suggest an alternative to the visitor, send information about the error to a logging facility, ... . All much better than just dying.
 
 ## Throwing our own errors
 
-What if `json` is syntactically correct... But doesn't have a required `"name"` property?
+What if `json` is syntactically correct, but doesn't have a required `name` property?
 
 Like this:
 
@@ -243,7 +243,7 @@ try {
 }
 ```
 
-Here `JSON.parse` runs normally, but the absence of `"name"` is actually an error for us.
+Here `JSON.parse` runs normally, but the absence of `name` is actually an error for us.
 
 To unify error handling, we'll use the `throw` operator.
 
@@ -297,7 +297,7 @@ try {
 
 As we can see, that's a `SyntaxError`.
 
-...And in our case, the absense of `name` could be treated as a syntax error also, assuming that users must have a `"name"`.
+And in our case, the absense of `name` could be treated as a syntax error also, assuming that users must have a `name`.
 
 So let's throw it:
 
@@ -321,7 +321,7 @@ try {
 }
 ```
 
-In the line `(*)` the `throw` operator generates `SyntaxError` with the given `message`, the same way as JavaScript would generate itself. The execution of `try` immediately stops and the control flow jumps into `catch`.
+In the line `(*)`, the `throw` operator generates a `SyntaxError` with the given `message`, the same way as JavaScript would generate it itself. The execution of `try` immediately stops and the control flow jumps into `catch`.
 
 Now `catch` became a single place for all error handling: both for `JSON.parse` and other cases.
 
@@ -340,7 +340,7 @@ try {
   // ...
 } catch(err) {
   alert("JSON Error: " + err); // JSON Error: ReferenceError: user is not defined
-  // (not JSON Error actually)
+  // (no JSON Error actually)
 }
 ```
 
@@ -480,7 +480,7 @@ The code has two ways of execution:
 
 The `finally` clause is often used when we start doing something before `try..catch` and want to finalize it in any case of outcome.
 
-For instance, we want to measure time that a Fibonacci numbers function `fib(n)` takes. Naturally, we can start measuring before it runs and finish afterwards. But what if there's an error during the function call? In particular, the implementation of `fib(n)` in the code below returns an error for negative or non-integer numbers.
+For instance, we want to measure the time that a Fibonacci numbers function `fib(n)` takes. Naturally, we can start measuring before it runs and finish afterwards. But what if there's an error during the function call? In particular, the implementation of `fib(n)` in the code below returns an error for negative or non-integer numbers.
 
 The `finally` clause is a great place to finish the measurements no matter what.
 
@@ -527,7 +527,7 @@ Otherwise, if `let` were made inside the `{...}` block, it would only be visible
 ```
 
 ````smart header="`finally` and `return`"
-Finally clause works for *any* exit from `try..catch`. That includes an explicit `return`.
+The `finally` clause works for *any* exit from `try..catch`. That includes an explicit `return`.
 
 In the example below, there's a `return` in `try`. In this case, `finally` is executed just before the control returns to the outer code.