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-15Lines changed: 15 additions & 15 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -79,7 +79,7 @@ Let's see more examples.
79
79
````warn header="`try..catch` only works for runtime errors"
80
80
For `try..catch` to work, the code must be runnable. In other words, it should be valid JavaScript.
81
81
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:
83
83
84
84
```js run
85
85
try {
@@ -96,7 +96,7 @@ So, `try..catch` can only handle errors that occur in the valid code. Such error
96
96
97
97
98
98
````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:
100
100
101
101
```js run
102
102
try {
@@ -108,7 +108,7 @@ try {
108
108
}
109
109
```
110
110
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.
112
112
113
113
To catch an exception inside a scheduled function, `try..catch` must be inside that function:
114
114
```js run
@@ -170,9 +170,9 @@ try {
170
170
171
171
Let's explore a real-life use case of `try..catch`.
172
172
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.
174
174
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.
176
176
177
177
We receive it and call `JSON.parse`, like this:
178
178
@@ -188,13 +188,13 @@ alert( user.name ); // John
188
188
alert( user.age ); // 30
189
189
```
190
190
191
-
More detailed information about JSONyou can find in the chapter <info:json>.
191
+
You can find more detailed information about JSONin the <info:json> chapter.
192
192
193
193
**If `json` is malformed, `JSON.parse` generates an error, so the script "dies".**
194
194
195
195
Should we be satisfied with that? Of course, not!
196
196
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.
198
198
199
199
Let's use `try..catch` to handle the error:
200
200
@@ -218,11 +218,11 @@ try {
218
218
}
219
219
```
220
220
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.
222
222
223
223
## Throwing our own errors
224
224
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?
226
226
227
227
Like this:
228
228
@@ -241,7 +241,7 @@ try {
241
241
}
242
242
```
243
243
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.
245
245
246
246
To unify error handling, we'll use the `throw` operator.
247
247
@@ -295,7 +295,7 @@ try {
295
295
296
296
As we can see, that's a `SyntaxError`.
297
297
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`.
299
299
300
300
So let's throw it:
301
301
@@ -319,7 +319,7 @@ try {
319
319
}
320
320
```
321
321
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`.
323
323
324
324
Now `catch` became a single place for all error handling: both for `JSON.parse` and other cases.
325
325
@@ -338,7 +338,7 @@ try {
338
338
// ...
339
339
} catch(err) {
340
340
alert("JSON Error: "+ err); // JSON Error: ReferenceError: user is not defined
341
-
// (not JSON Error actually)
341
+
// (no JSON Error actually)
342
342
}
343
343
```
344
344
@@ -478,7 +478,7 @@ The code has two ways of execution:
478
478
479
479
The `finally` clause is often used when we start doing something before `try..catch` and want to finalize it in any case of outcome.
480
480
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.
482
482
483
483
The `finally` clause is a great place to finish the measurements no matter what.
484
484
@@ -525,7 +525,7 @@ Otherwise, if `let` were made inside the `{...}` block, it would only be visible
525
525
```
526
526
527
527
````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`.
529
529
530
530
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