You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: 1-js/08-error-handling/1-try-catch/article.md
+15-15
Original file line number
Diff line number
Diff line change
@@ -81,7 +81,7 @@ Let's see more examples.
81
81
````warn header="`try..catch` only works for runtime errors"
82
82
For `try..catch` to work, the code must be runnable. In other words, it should be valid JavaScript.
83
83
84
-
It won't work if the code is syntactically wrong, for instance it has unmatched figure brackets:
84
+
It won't work if the code is syntactically wrong, for instance it has unmatched curly braces:
85
85
86
86
```js run
87
87
try {
@@ -98,7 +98,7 @@ So, `try..catch` can only handle errors that occur in the valid code. Such error
98
98
99
99
100
100
````warn header="`try..catch` works synchronously"
101
-
If an exception happens in a "scheduled" code, like in `setTimeout`, then `try..catch` won't catch it:
101
+
If an exception happens in "scheduled" code, like in `setTimeout`, then `try..catch` won't catch it:
102
102
103
103
```js run
104
104
try {
@@ -110,7 +110,7 @@ try {
110
110
}
111
111
```
112
112
113
-
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.
113
+
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.
114
114
115
115
To catch an exception inside a scheduled function, `try..catch` must be inside that function:
116
116
```js run
@@ -172,9 +172,9 @@ try {
172
172
173
173
Let's explore a real-life use case of `try..catch`.
174
174
175
-
As we already know, JavaScript supports method [JSON.parse(str)](mdn:js/JSON/parse) to read JSON-encoded values.
175
+
As we already know, JavaScript supports the [JSON.parse(str)](mdn:js/JSON/parse) method to read JSON-encoded values.
176
176
177
-
Usually it's used to decode the data received over the network, from the server or another source.
177
+
Usually it's used to decode data received over the network, from the server or another source.
178
178
179
179
We receive it and call `JSON.parse`, like this:
180
180
@@ -190,13 +190,13 @@ alert( user.name ); // John
190
190
alert( user.age ); // 30
191
191
```
192
192
193
-
More detailed information about JSONyou can find in the chapter <info:json>.
193
+
You can find more detailed information about JSONin the <info:json> chapter.
194
194
195
195
**If `json` is malformed, `JSON.parse` generates an error, so the script "dies".**
196
196
197
197
Should we be satisfied with that? Of course, not!
198
198
199
-
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.
199
+
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.
200
200
201
201
Let's use `try..catch` to handle the error:
202
202
@@ -220,11 +220,11 @@ try {
220
220
}
221
221
```
222
222
223
-
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.
223
+
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.
224
224
225
225
## Throwing our own errors
226
226
227
-
What if `json` is syntactically correct... But doesn't have a required `"name"` property?
227
+
What if `json` is syntactically correct, but doesn't have a required `name` property?
228
228
229
229
Like this:
230
230
@@ -243,7 +243,7 @@ try {
243
243
}
244
244
```
245
245
246
-
Here `JSON.parse` runs normally, but the absence of `"name"` is actually an error for us.
246
+
Here `JSON.parse` runs normally, but the absence of `name` is actually an error for us.
247
247
248
248
To unify error handling, we'll use the `throw` operator.
249
249
@@ -297,7 +297,7 @@ try {
297
297
298
298
As we can see, that's a `SyntaxError`.
299
299
300
-
...And in our case, the absense of `name` could be treated as a syntax error also, assuming that users must have a `"name"`.
300
+
And in our case, the absense of `name` could be treated as a syntax error also, assuming that users must have a `name`.
301
301
302
302
So let's throw it:
303
303
@@ -321,7 +321,7 @@ try {
321
321
}
322
322
```
323
323
324
-
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`.
324
+
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`.
325
325
326
326
Now `catch` became a single place for all error handling: both for `JSON.parse` and other cases.
327
327
@@ -340,7 +340,7 @@ try {
340
340
// ...
341
341
} catch(err) {
342
342
alert("JSON Error: "+ err); // JSON Error: ReferenceError: user is not defined
343
-
// (not JSON Error actually)
343
+
// (no JSON Error actually)
344
344
}
345
345
```
346
346
@@ -480,7 +480,7 @@ The code has two ways of execution:
480
480
481
481
The `finally` clause is often used when we start doing something before `try..catch` and want to finalize it in any case of outcome.
482
482
483
-
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.
483
+
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.
484
484
485
485
The `finally` clause is a great place to finish the measurements no matter what.
486
486
@@ -527,7 +527,7 @@ Otherwise, if `let` were made inside the `{...}` block, it would only be visible
527
527
```
528
528
529
529
````smart header="`finally` and `return`"
530
-
Finally clause works for *any* exit from `try..catch`. That includes an explicit `return`.
530
+
The `finally` clause works for *any* exit from `try..catch`. That includes an explicit `return`.
531
531
532
532
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.
0 commit comments