Skip to content

Commit 4feed7d

Browse files
authored
Merge pull request #274 from ockley/master
Error handling, "try..catch"
2 parents 6d7e882 + d82d85f commit 4feed7d

4 files changed

Lines changed: 309 additions & 220 deletions

File tree

Lines changed: 12 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -1,47 +1,47 @@
1-
The difference becomes obvious when we look at the code inside a function.
1+
Forskellen bliver tydelig, når vi kigger på koden inde i en funktion.
22

3-
The behavior is different if there's a "jump out" of `try...catch`.
3+
Det er forskelligt, hvis der er et "spring ud" af `try...catch`.
44

5-
For instance, when there's a `return` inside `try...catch`. The `finally` clause works in case of *any* exit from `try...catch`, even via the `return` statement: right after `try...catch` is done, but before the calling code gets the control.
5+
For eksempel, når der er en `return` inde i `try...catch`. `finally`-klausulen virker i tilfældet af *hvilken som helst* afslutning fra `try...catch`, selv via `return`-sætningen: lige efter `try...catch` er færdig, men før den kaldende kode får kontrollen.
66

77
```js run
88
function f() {
99
try {
1010
alert('start');
1111
*!*
12-
return "result";
12+
return "resultat";
1313
*/!*
1414
} catch (err) {
1515
/// ...
1616
} finally {
17-
alert('cleanup!');
17+
alert('oprydning!');
1818
}
1919
}
2020

21-
f(); // cleanup!
21+
f(); // oprydning!
2222
```
2323

24-
...Or when there's a `throw`, like here:
24+
...eller hvis der er en `throw`, som her:
2525

2626
```js run
2727
function f() {
2828
try {
2929
alert('start');
30-
throw new Error("an error");
30+
throw new Error("en fejl");
3131
} catch (err) {
3232
// ...
33-
if("can't handle the error") {
33+
if("kan ikke håndtere fejlen") {
3434
*!*
3535
throw err;
3636
*/!*
3737
}
3838

3939
} finally {
40-
alert('cleanup!')
40+
alert('oprydning!')
4141
}
4242
}
4343

44-
f(); // cleanup!
44+
f(); // oprydning!
4545
```
4646

47-
It's `finally` that guarantees the cleanup here. If we just put the code at the end of `f`, it wouldn't run in these situations.
47+
Det er `finally` der garanterer oprydningen her. Hvis vi bare sætter koden ved slutningen af `f`, ville den ikke køre i disse situationer.

1-js/10-error-handling/1-try-catch/1-finally-or-code-after/task.md

Lines changed: 11 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -4,35 +4,35 @@ importance: 5
44

55
# Finally or just the code?
66

7-
Compare the two code fragments.
7+
Sammenlign disse to kodefragmenter.
88

9-
1. The first one uses `finally` to execute the code after `try...catch`:
9+
1. Den første bruger `finally` til at køre koden efter `try...catch`:
1010

1111
```js
1212
try {
13-
work work
13+
arbejd' arbejd'
1414
} catch (err) {
15-
handle errors
15+
håndter fejl
1616
} finally {
1717
*!*
18-
cleanup the working space
18+
ryd op på arbejdspladsen
1919
*/!*
2020
}
2121
```
22-
2. The second fragment puts the cleaning right after `try...catch`:
22+
2. Den anden placerer oprydningen lige efter `try...catch`:
2323

2424
```js
2525
try {
26-
work work
26+
arbejd' arbejd'
2727
} catch (err) {
28-
handle errors
28+
håndter fejl
2929
}
3030
3131
*!*
32-
cleanup the working space
32+
ryd op på arbejdspladsen
3333
*/!*
3434
```
3535

36-
We definitely need the cleanup after the work, doesn't matter if there was an error or not.
36+
Vi skal selvfølgelig have oprydningen efter arbejdet, uanset om der var en fejl eller ej.
3737

38-
Is there an advantage here in using `finally` or both code fragments are equal? If there is such an advantage, then give an example when it matters.
38+
Er der en fordel i at bruge `finally` eller er de to kodefragmenter ens? Hvis der er en sådan fordel, så giv et eksempel på, når det betyder noget.

0 commit comments

Comments
 (0)