Repository navigation
Error handling, try...catch - #466
Conversation
|
|
gabifs
left a comment
gabifs
left a comment
There was a problem hiding this comment.
Obrigado pela tradução! Deixei alguns comentários inline sobre estrangeirismos, trechos traduzidos de forma muito literal e strings que ficaram em inglês.
Diagrama: o try-catch-flow.svg continua com os textos em inglês ("Begin", "No Errors", "An error occured in the code", "Ignore catch block", "Ignore the rest of try", "Execute catch block"). Dá pra adicionar uma entrada no images.yml com as traduções? Por exemplo:
try-catch-flow.svg:
"Begin":
text: "Início"
position: center
"No Errors":
text: "Sem erros"
position: center
"An error occured in the code":
text: "Ocorreu um erro no código"
position: center
"Ignore catch block":
text: "Ignora o bloco catch"
position: center
"Ignore the rest of try":
text: "Ignora o resto do try"
position: center
"Execute catch block":
text: "Executa o bloco catch"
position: center| ``` | ||
|
|
||
| The JavaScript engine first reads the code, and then runs it. The errors that occur on the reading phase are called "parse-time" errors and are unrecoverable (from inside that code). That's because the engine can't understand the code. | ||
| O motor do JavaScript primeiro lê o código, e só depois o executa. Os erros que ocorrem na fase de leitura são chamados de erros de "parse-time" (tempo de análise), e são irrecuperáveis (de dentro daquele código). Isso acontece porque o motor não consegue entender o código. |
There was a problem hiding this comment.
Acho que dá pra tirar o termo em inglês e deixar só a tradução:
| O motor do JavaScript primeiro lê o código, e só depois o executa. Os erros que ocorrem na fase de leitura são chamados de erros de "parse-time" (tempo de análise), e são irrecuperáveis (de dentro daquele código). Isso acontece porque o motor não consegue entender o código. | |
| O motor do JavaScript primeiro lê o código, e só depois o executa. Os erros que ocorrem na fase de leitura são chamados de erros de "tempo de análise" (*parse-time*), e são irrecuperáveis (de dentro daquele código). Isso acontece porque o motor não consegue entender o código. |
| ``` | ||
|
|
||
| ## Optional "catch" binding | ||
| ## Ligação opcional do "catch" |
There was a problem hiding this comment.
"Ligação" é tradução literal de binding e fica confuso pra quem lê. Que tal:
| ## Ligação opcional do "catch" | |
| ## Parâmetro opcional do "catch" |
| [recent browser=new] | ||
|
|
||
| If we don't need error details, `catch` may omit it: | ||
| Se não precisarmos dos detalhes do erro, o `catch` pode omiti-los: |
There was a problem hiding this comment.
No original, "catch may omit it" quer dizer que o parâmetro (err) pode ser omitido, e não os detalhes do erro. Sugestão:
| Se não precisarmos dos detalhes do erro, o `catch` pode omiti-los: | |
| Se não precisarmos dos detalhes do erro, o `catch` pode omitir o parâmetro: |
| Geralmente ele é usado para decodificar dados recebidos pela rede, do servidor ou de outra fonte. | ||
|
|
||
| We receive it and call `JSON.parse` like this: | ||
| Nós recebemos e chamamos `JSON.parse` assim: |
There was a problem hiding this comment.
A frase ficou sem objeto (recebemos o quê?):
| Nós recebemos e chamamos `JSON.parse` assim: | |
| Recebemos os dados e chamamos `JSON.parse` assim: |
| ``` | ||
|
|
||
| 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. | ||
| Aqui usamos o bloco `catch` só pra mostrar a mensagem, mas podemos fazer muito mais: enviar uma nova requisição de rede, sugerir uma alternativa ao visitante, enviar informações sobre o erro pra um serviço de log, ... . Tudo isso é bem melhor do que simplesmente morrer. |
There was a problem hiding this comment.
Pra evitar estrangeirismo:
| Aqui usamos o bloco `catch` só pra mostrar a mensagem, mas podemos fazer muito mais: enviar uma nova requisição de rede, sugerir uma alternativa ao visitante, enviar informações sobre o erro pra um serviço de log, ... . Tudo isso é bem melhor do que simplesmente morrer. | |
| Aqui usamos o bloco `catch` só pra mostrar a mensagem, mas podemos fazer muito mais: enviar uma nova requisição de rede, sugerir uma alternativa ao visitante, enviar informações sobre o erro pra um serviço de registro, ... . Tudo isso é bem melhor do que simplesmente morrer. |
| ``` | ||
|
|
||
| We can also get the error class name from `err.name` property. All native errors have it. Another option is to read `err.constructor.name`. | ||
| Também podemos obter o nome da classe do erro pela propriedade `err.name`. Todos os erros nativos têm ela. Outra opção é ler `err.constructor.name`. |
There was a problem hiding this comment.
| Também podemos obter o nome da classe do erro pela propriedade `err.name`. Todos os erros nativos têm ela. Outra opção é ler `err.constructor.name`. | |
| Também podemos obter o nome da classe do erro pela propriedade `err.name`. Todos os erros nativos a possuem. Outra opção é ler `err.constructor.name`. |
| O erro lançado na linha `(*)`, de dentro do bloco `catch`, "cai fora" do `try...catch` e pode ser capturado por um `try...catch` externo (se existir), ou mata o script. | ||
|
|
||
| So the `catch` block actually handles only errors that it knows how to deal with and "skips" all others. | ||
| Então o bloco `catch`, na verdade, só trata os erros que ele sabe como lidar, e "pula" todos os outros. |
There was a problem hiding this comment.
Falta a preposição que o "lidar" pede:
| Então o bloco `catch`, na verdade, só trata os erros que ele sabe como lidar, e "pula" todos os outros. | |
| Então o bloco `catch`, na verdade, só trata os erros com que sabe lidar, e "pula" todos os outros. |
| } catch (err) { | ||
| *!* | ||
| alert( "External catch got: " + err ); // caught it! | ||
| alert( "External catch got: " + err ); // capturou! |
There was a problem hiding this comment.
O comentário foi traduzido, mas a string não:
| alert( "External catch got: " + err ); // capturou! | |
| alert( "Catch externo capturou: " + err ); // capturou! |
| Aqui o `finally` garante que o tempo será medido corretamente nas duas situações -- tanto em caso de uma execução bem-sucedida do `fib` quanto em caso de erro nela: | ||
|
|
||
| ```js run | ||
| let num = +prompt("Enter a positive integer number?", 35) |
There was a problem hiding this comment.
As strings desse exemplo continuam em inglês ("Enter a positive integer number?", "Must not be negative, and also an integer.", "error occurred", `execution took ${diff}ms`), mas o texto logo abaixo pede pro leitor digitar 35 no prompt. Sugestão: "Digite um número inteiro positivo:", "Não pode ser negativo, e deve ser inteiro.", "ocorreu um erro", `a execução levou ${diff}ms`.
| } | ||
|
|
||
| alert( func() ); // first works alert from finally, and then this one | ||
| alert( func() ); // primeiro funciona o alert do finally, e depois esse aqui |
There was a problem hiding this comment.
"funciona" ficou literal demais (vem de "first works alert from finally"):
| alert( func() ); // primeiro funciona o alert do finally, e depois esse aqui | |
| alert( func() ); // primeiro executa o alert do finally, e depois este |
|
Obrigado pela revisão detalhada, @gabifs! Apliquei todas as sugestões de texto (estrangeirismos, traduções literais e strings que ficaram em inglês). Sobre o diagrama: montei o pipeline de tradução de imagens (server + engine + ImageMagick) e traduzi o |
Tradução do artigo "Error handling, try...catch" para o português, incluindo o exercício.
Conforme comentado na #1.