Error handling, "try..catch" #90
Conversation
|
VibingCreator seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. You have signed the CLA already but the status is still pending? Let us recheck it. |
| @@ -1,47 +1,47 @@ | |||
| The difference becomes obvious when we look at the code inside a function. | |||
| Jeśli umieścimy pierwszy fragment w środku funkcji, szybko zauważymy różnicę. | |||
There was a problem hiding this comment.
W tłumaczeniu jest trochę zmienione znaczenie, "szybko", to nie to samo co "becomes obvious"
|
|
||
| The behavior is different if there's a "jump out" of `try..catch`. | ||
| Występuje ona w momencie wyjścia z instrukcji `try...catch`. |
There was a problem hiding this comment.
Tutaj również zmienione jest znaczenie. Nie mówię, że powinno być 100% słowo w słowo, ale znaczeniowo trochę odbiega od oryginału
| } catch (e) { | ||
| // ... | ||
| if("can't handle the error") { | ||
| if("nie interesują mnie błędy") { |
|
|
||
| 1. The first one uses `finally` to execute the code after `try..catch`: | ||
| 1. Pierwszy fragment zawiera blok `finally`, naturalnie wykona się jako ostatni ze wszystkich bloków instrukcji: |
|
|
||
| But there's a syntax construct `try..catch` that allows to "catch" errors and, instead of dying, do something more reasonable. | ||
| Przy użyciu instrukcji `try...catch`, możemy obsłużyć błędy w bardziej sensowny sposób. |
There was a problem hiding this comment.
Fajnie by było uwzględnić jeszcze jakoś ten fragment "instead of dying", to ważne, że przy try...catch nie powodujemy zatrzymania skryptu
|
|
||
| } | ||
| ``` | ||
|
|
||
| ````warn header="`try...catch` umożliwia obsługę błędów napotkanych tylko w trakcie wykonywania się programu (ang. Runtime Errors)" |
There was a problem hiding this comment.
Proszę umieść to na tej samej linii kodu co angielska wersja, zgodnie z instrukcją w repozytorium
| } | ||
| ``` | ||
| Silnik JavaScript najpierw odczytuje kod, a dopiero potem go wykonuje. Błędy podczas fazy analizy kodu nie mogą zostać obsłużone w pierwszym bloku instrukcji, ponieważ niepoprawnie komunikujemy się z silnikiem. |
|
|
||
| `stack` | ||
| : Current call stack: a string with information about the sequence of nested calls that led to the error. Used for debugging purposes. |
There was a problem hiding this comment.
Warto dodać w nawiasie (ang. call stack)
| // ... | ||
| } | ||
| ``` | ||
|
|
||
| ## Using "try..catch" | ||
| ## Zastosowanie "try...catch" w życiu codziennym |
There was a problem hiding this comment.
Po co dopisek "w życiu codziennym"?
|
|
||
| As we already know, JavaScript supports the [JSON.parse(str)](mdn:js/JSON/parse) method to read JSON-encoded values. | ||
| Na tym etapie powinniśmy już wiedzieć o metodzie [JSON.parse(str)](mdn:js/JSON/parse), która umożliwia nam przetworzenie obiektu JSON. |
There was a problem hiding this comment.
Lepiej trzymać się tu oryginalnej wersji "Jak już wiemy".
"Powinniśmy" może stawiać czytelnika w pozycji, nomen omen, powinności, co nie jest tu dobrym konstruktem
|
Please make the requested changes. After it, add a comment "/done". |
|
Hej, zacząłem tłumaczyć ten rozdział. Czy dany pull request jest jeszcze w miarę aktualny i powinienem przestać tłumaczyć czy jak? Na liście tłumaczeń nie było tego tematu zajętego. |
|
Hej, wydaje mi się, że jeśli nie było nikogo przypisanego, to możesz śmiało jechać z tematem 🙂 |
|
@RafalMichniuk Co do ilości tłumaczonych tematów w jednym momencie - teoretycznie masz rację, ale tematy, które wziąłem są ze sobą ściśle powiązane. Więc wolałem się za nie zabrać w 100%. Z drugiej strony widzę, że tłumaczenia idą jak krew z nosa, więc akurat w tym przypadku cieszmy się, że ktokolwiek chce to tłumaczyć. |
|
Przyznaję, że w tym wypadku oczywiście masz rację, jednak na przyszłość postaraj się trzymać wytycznych zawartych w opisie dla tłumaczących: For New Translators |
|
Luzik arbuzik :) |
No description provided.