Skip to content

Commit 4fbbd6c

Browse files
authored
Merge pull request #386 from brentguf/try-catch
Try...catch chapter
2 parents bf14b2f + f236a13 commit 4fbbd6c

File tree

1 file changed

+15
-15
lines changed

1 file changed

+15
-15
lines changed

1-js/08-error-handling/1-try-catch/article.md

Lines changed: 15 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -79,7 +79,7 @@ Let's see more examples.
7979
````warn header="`try..catch` only works for runtime errors"
8080
For `try..catch` to work, the code must be runnable. In other words, it should be valid JavaScript.
8181

82-
It won't work if the code is syntactically wrong, for instance it has unmatched figure brackets:
82+
It won't work if the code is syntactically wrong, for instance it has unmatched curly braces:
8383
8484
```js run
8585
try {
@@ -96,7 +96,7 @@ So, `try..catch` can only handle errors that occur in the valid code. Such error
9696
9797
9898
````warn header="`try..catch` works synchronously"
99-
If an exception happens in a "scheduled" code, like in `setTimeout`, then `try..catch` won't catch it:
99+
If an exception happens in "scheduled" code, like in `setTimeout`, then `try..catch` won't catch it:
100100

101101
```js run
102102
try {
@@ -108,7 +108,7 @@ try {
108108
}
109109
```
110110

111-
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.
111+
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.
112112
113113
To catch an exception inside a scheduled function, `try..catch` must be inside that function:
114114
```js run
@@ -170,9 +170,9 @@ try {
170170

171171
Let's explore a real-life use case of `try..catch`.
172172
173-
As we already know, JavaScript supports method [JSON.parse(str)](mdn:js/JSON/parse) to read JSON-encoded values.
173+
As we already know, JavaScript supports the [JSON.parse(str)](mdn:js/JSON/parse) method to read JSON-encoded values.
174174
175-
Usually it's used to decode the data received over the network, from the server or another source.
175+
Usually it's used to decode data received over the network, from the server or another source.
176176

177177
We receive it and call `JSON.parse`, like this:
178178

@@ -188,13 +188,13 @@ alert( user.name ); // John
188188
alert( user.age ); // 30
189189
```
190190

191-
More detailed information about JSON you can find in the chapter <info:json>.
191+
You can find more detailed information about JSON in the <info:json> chapter.
192192

193193
**If `json` is malformed, `JSON.parse` generates an error, so the script "dies".**
194194

195195
Should we be satisfied with that? Of course, not!
196196

197-
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.
197+
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.
198198

199199
Let's use `try..catch` to handle the error:
200200
@@ -218,11 +218,11 @@ try {
218218
}
219219
```
220220
221-
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.
221+
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.
222222
223223
## Throwing our own errors
224224
225-
What if `json` is syntactically correct... But doesn't have a required `"name"` property?
225+
What if `json` is syntactically correct, but doesn't have a required `name` property?
226226
227227
Like this:
228228
@@ -241,7 +241,7 @@ try {
241241
}
242242
```
243243
244-
Here `JSON.parse` runs normally, but the absence of `"name"` is actually an error for us.
244+
Here `JSON.parse` runs normally, but the absence of `name` is actually an error for us.
245245
246246
To unify error handling, we'll use the `throw` operator.
247247
@@ -295,7 +295,7 @@ try {
295295
296296
As we can see, that's a `SyntaxError`.
297297
298-
...And in our case, the absense of `name` could be treated as a syntax error also, assuming that users must have a `"name"`.
298+
And in our case, the absense of `name` could be treated as a syntax error also, assuming that users must have a `name`.
299299
300300
So let's throw it:
301301
@@ -319,7 +319,7 @@ try {
319319
}
320320
```
321321
322-
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`.
322+
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`.
323323
324324
Now `catch` became a single place for all error handling: both for `JSON.parse` and other cases.
325325
@@ -338,7 +338,7 @@ try {
338338
// ...
339339
} catch(err) {
340340
alert("JSON Error: " + err); // JSON Error: ReferenceError: user is not defined
341-
// (not JSON Error actually)
341+
// (no JSON Error actually)
342342
}
343343
```
344344
@@ -478,7 +478,7 @@ The code has two ways of execution:
478478
479479
The `finally` clause is often used when we start doing something before `try..catch` and want to finalize it in any case of outcome.
480480
481-
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.
481+
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.
482482
483483
The `finally` clause is a great place to finish the measurements no matter what.
484484
@@ -525,7 +525,7 @@ Otherwise, if `let` were made inside the `{...}` block, it would only be visible
525525
```
526526
527527
````smart header="`finally` and `return`"
528-
Finally clause works for *any* exit from `try..catch`. That includes an explicit `return`.
528+
The `finally` clause works for *any* exit from `try..catch`. That includes an explicit `return`.
529529
530530
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.
531531

0 commit comments

Comments
 (0)