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
+20-18Lines changed: 20 additions & 18 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -460,7 +460,7 @@ The extended syntax looks like this:
460
460
}
461
461
```
462
462
463
-
Try to run this?
463
+
Try running this code:
464
464
465
465
```js run
466
466
try {
@@ -473,16 +473,18 @@ try {
473
473
}
474
474
```
475
475
476
-
The code has two variants:
476
+
The code has two ways of execution:
477
477
478
-
1. If say answer "Yes" to error, then `try->catch->finally`.
479
-
2. If say "No", then `try->finally`.
478
+
1. If you answer "Yes" to "Make an error?", then `try->catch->finally`.
479
+
2. If you say "No", then `try->finally`.
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
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 is 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
-
The `finally` clause is a great place to finish the measurements no matter how the function finishes.
485
+
The `finally` clause is a great place to finish the measurements no matter what.
486
+
487
+
Here `finally` guarantees that the time will be measured correctly in both situations -- in case of a successful execution of `fib` and in case of an error in it:
486
488
487
489
```js run
488
490
let num =+prompt("Enter a positive integer number?", 35)
Here `finally` guarantees that the time will be measured correctly in both situations -- in case of a successful execution of `fib` and in case of an error in it.
517
-
518
-
You can check that by running the code with `num=35` -- executes normally, `finally` after `try`, and then with `num=-1`, there will be an immediate error, an the execution will take `0ms`.
518
+
You can check by running the code with entering `35` into `prompt` -- it executes normally, `finally` after `try`. And then enter `-1` -- there will be an immediate error, an the execution will take `0ms`. Both measurements are done correctly.
519
519
520
-
In other words, there may be two ways to exist from a function: either a `return` or `throw`. The `finally` handles them both.
520
+
In other words, there may be two ways to exit a function: either a `return` or `throw`. The `finally` clause handles them both.
521
521
522
522
523
-
```smart header="Variables are local to try..catch..finally clauses"
523
+
```smart header="Variables are local inside `try..catch..finally`"
524
524
Please note that `result` and `diff` variables in the code above are declared *before*`try..catch`.
525
525
526
-
Otherwise, if`let` were made inside the `{...}`clause, it would only be visible inside of it.
526
+
Otherwise, if`let` were made inside the `{...}`block, it would only be visible inside of it.
527
527
```
528
528
529
529
````smart header="`finally` and `return`"
530
-
Finally clause works for *any* exit from `try..catch`. That includes the `return` directive.
530
+
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.
533
533
534
534
```js run
535
535
functionfunc() {
536
536
537
537
try {
538
+
*!*
538
539
return1;
540
+
*/!*
539
541
540
542
} catch (e) {
541
543
/* ... */
@@ -556,15 +558,15 @@ The `try..finally` construct, without `catch` clause, is also useful. We apply i
556
558
557
559
```js
558
560
functionfunc() {
559
-
// start doing something that needs completion
561
+
// start doing something that needs completion (like measurements)
560
562
try {
561
563
// ...
562
564
} finally {
563
565
// complete that thing even if all dies
564
566
}
565
567
}
566
568
```
567
-
In the code above, an error inside `try` always falls out, because there's no `catch`. But `finally`triggers before that.
569
+
In the code above, an error inside `try` always falls out, because there's no `catch`. But `finally`works before the execution flow jumps outside.
568
570
````
569
571
570
572
## Global catch
@@ -573,9 +575,9 @@ In the code above, an error inside `try` always falls out, because there's no `c
573
575
The information from this section is not a part of the core Javascript.
574
576
```
575
577
576
-
Let's imagine we've got a fatal error outside of `try..catch`, and the script died.
578
+
Let's imagine we've got a fatal error outside of `try..catch`, and the script died. Like a programming error that no `try..catch` doesn't know how to handle, or something else terrible.
577
579
578
-
Is there a way to react on it? We may want to log the error, show something to the user (normally he doesn't see the error message) etc.
580
+
Is there a way to react on such happening? We may want to log the error, show something to the user (normally he doesn't see the error message) etc.
579
581
580
582
There is none in the specification, but environments usually provide it, because it's really handy. For instance, Node.JS has [process.on('uncaughtException')](https://nodejs.org/api/process.html#process_event_uncaughtexception) for that. And in the browser we can assign a function to special [window.onerror](mdn:api/GlobalEventHandlers/onerror) property. It will run in case of an uncaught error.
581
583
@@ -617,9 +619,9 @@ For instance:
617
619
</script>
618
620
```
619
621
620
-
The role of the global handler is usually not to recover the script execution -- that's probably impossible, but to send the error message to developers.
622
+
The role of the global handler `window.onerror`is usually not to recover the script execution -- that's probably impossible in case of programming errors, but to send the error message to developers.
621
623
622
-
There are also web-services that provide error-logging facilities, like <https://errorception.com> or <http://www.muscula.com>. They give a script with custom `window.onerror` function, and once inserted into a page, it reports about all errors it gets to their server. Afterwards developers can browse them and get notifications on email about fresh errors.
624
+
There are also web-services that provide error-logging facilities for such cases, like <https://errorception.com> or <http://www.muscula.com>. They give a script with custom `window.onerror` function, and once inserted into a page, it reports about all errors it gets to their server. Afterwards developers can browse them and get notifications on email about fresh errors.
0 commit comments