Repository navigation
Async/await - #470
Merged
gabifs merged 2 commits intoNov 8, 2026
Merged
Async/await#470
Conversation
gabifs
reviewed
Nov 7, 2026
| Então deveríamos esperar até que todas as promessas sejam estabelecidas antes de seguir com a execução e eventualmente desconectar. | ||
|
|
||
| Here's another implementation. It behaves similar to `Promise.all` - also resolves with the first error, but waits until all promises are settled. | ||
| Aqui está outra implementação. Ela se comporta de forma parecida com o `Promise.all` - também resolve com o primeiro erro, mas espera até que todas as promessas sejam estabelecidas. |
Contributor
There was a problem hiding this comment.
"também resolve com o primeiro erro" contradiz o código logo abaixo: customPromiseAllWait chama reject(firstError), então ela rejeita com o primeiro erro (o texto em inglês já tem esse deslize, mas a tradução é uma boa hora de corrigir). Quem ler vai achar que o await devolve o erro como valor em vez de lançá-lo.
Suggested change
| Aqui está outra implementação. Ela se comporta de forma parecida com o `Promise.all` - também resolve com o primeiro erro, mas espera até que todas as promessas sejam estabelecidas. | |
| Aqui está outra implementação. Ela se comporta de forma parecida com o `Promise.all` - também rejeita com o primeiro erro, mas espera até que todas as promessas sejam estabelecidas. |
gabifs
reviewed
Nov 7, 2026
| No nosso caso, a segunda consulta falha, então o `Promise.all` rejeita, e o bloco `try...catch` captura esse erro. Enquanto isso, as outras promessas *não são afetadas* - elas continuam a execução de forma independente. No nosso caso, a terceira consulta lança um erro próprio depois de um tempo. E esse erro nunca é capturado, podemos ver isso no console. | ||
|
|
||
| The problem is especially dangerous in server-side environments, such as Node.js, when an uncaught error may cause the process to crash. | ||
| O problema é especialmente perigoso em ambientes do lado do servidor, como o Node.js, quando um erro não capturado pode fazer o processo travar. |
Contributor
There was a problem hiding this comment.
"travar" em português costuma significar congelar/ficar parado, mas "crash" aqui quer dizer que o processo do Node.js é encerrado por causa da rejeição não tratada. O leitor pode entender que o processo só fica pendurado.
Suggested change
| O problema é especialmente perigoso em ambientes do lado do servidor, como o Node.js, quando um erro não capturado pode fazer o processo travar. | |
| O problema é especialmente perigoso em ambientes do lado do servidor, como o Node.js, quando um erro não capturado pode fazer o processo ser encerrado. |
gabifs
reviewed
Nov 7, 2026
| Pode ser importante que todas as consultas se completem, especialmente se algumas delas fazem atualizações importantes. | ||
|
|
||
| So we should wait until all promises are settled before going further with the execution and eventually disconnecting. | ||
| Então deveríamos esperar até que todas as promessas sejam estabelecidas antes de seguir com a execução e eventualmente desconectar. |
Contributor
There was a problem hiding this comment.
"eventually" é falso cognato: "eventualmente" em português significa "ocasionalmente/talvez", enquanto o original quer dizer "por fim/no final". Do jeito que está, parece que desconectar é opcional.
Suggested change
| Então deveríamos esperar até que todas as promessas sejam estabelecidas antes de seguir com a execução e eventualmente desconectar. | |
| Então deveríamos esperar até que todas as promessas sejam estabelecidas antes de seguir com a execução e, por fim, desconectar. |
gabifs
reviewed
Nov 7, 2026
| Porém, a má notícia é que chamadas de serviço (como `database.query`) são frequentemente implementadas por uma biblioteca de terceiros que não suporta cancelamento. Nesse caso, não há como cancelar uma chamada. | ||
|
|
||
| As an alternative, we can write our own wrapper function around `Promise.all` which adds a custom `then/catch` handler to each promise to track them: results are gathered and, if an error occurs, all subsequent promises are ignored. | ||
| Como alternativa, podemos escrever nossa própria função wrapper ao redor do `Promise.all` que adiciona um tratador `then/catch` personalizado a cada promessa para rastreá-las: os resultados são reunidos e, se ocorrer um erro, todas as promessas seguintes são ignoradas. |
Contributor
There was a problem hiding this comment.
"wrapper" é estrangeirismo (aqui e na linha 87: "escrever um wrapper ao redor dele"). As diretrizes de tradução do repositório pedem para evitar palavras estrangeiras. Uma sugestão é "função que envolve o Promise.all" aqui e "escrever uma função que o envolve" na linha 87.
gabifs
reviewed
Nov 7, 2026
| Quando usamos `async/await`, raramente precisamos do `.then`, porque o `await` cuida da espera para nós. E podemos usar um `try..catch` normal em vez de `.catch`. Isso geralmente é (mas nem sempre) mais conveniente. | ||
|
|
||
| But at the top level of the code, when we're outside any `async` function, we're syntactically unable to use `await`, so it's a normal practice to add `.then/catch` to handle the final result or falling-through error, like in the line `(*)` of the example above. | ||
| Mas no nível superior do código, quando estamos fora de qualquer função `async`, não conseguimos usar `await` sintaticamente, então é uma prática normal adicionar `.then/catch` para tratar o resultado final ou o erro que "cai através", como na linha `(*)` do exemplo acima. |
Contributor
There was a problem hiding this comment.
"o erro que "cai através"" é uma tradução literal de "falling-through error" e fica difícil de entender. A ideia é o erro que não foi tratado em nenhum lugar antes e chega até ali.
Suggested change
| Mas no nível superior do código, quando estamos fora de qualquer função `async`, não conseguimos usar `await` sintaticamente, então é uma prática normal adicionar `.then/catch` para tratar o resultado final ou o erro que "cai através", como na linha `(*)` do exemplo acima. | |
| Mas no nível superior do código, quando estamos fora de qualquer função `async`, não conseguimos usar `await` sintaticamente, então é uma prática normal adicionar `.then/catch` para tratar o resultado final ou algum erro que não foi tratado, como na linha `(*)` do exemplo acima. |
gabifs
reviewed
Nov 7, 2026
| ````warn header="Can't use `await` in regular functions" | ||
| If we try to use `await` in a non-async function, there would be a syntax error: | ||
| ````warn header="Não dá para usar `await` em funções comuns" | ||
| Se tentarmos usar `await` em uma função que não seja `async`, haveria um erro de sintaxe: |
Contributor
There was a problem hiding this comment.
Os tempos verbais não combinam: "Se tentarmos" (futuro do subjuntivo) pede futuro do presente, não "haveria".
Suggested change
| Se tentarmos usar `await` em uma função que não seja `async`, haveria um erro de sintaxe: | |
| Se tentarmos usar `await` em uma função que não seja `async`, teremos um erro de sintaxe: |
gabifs
reviewed
Nov 7, 2026
| ````smart header="Modern browsers allow top-level `await` in modules" | ||
| In modern browsers, `await` on top level works just fine, when we're inside a module. We'll cover modules in article <info:modules-intro>. | ||
| ````smart header="Navegadores modernos permitem `await` de nível superior em módulos" | ||
| Em navegadores modernos, o `await` em nível superior funciona perfeitamente bem, quando estamos dentro de um módulo. Vamos cobrir módulos no artigo <info:modules-intro>. |
Contributor
There was a problem hiding this comment.
"Vamos cobrir módulos" é uma tradução literal de "cover". Em português, "abordar" soa mais natural.
Suggested change
| Em navegadores modernos, o `await` em nível superior funciona perfeitamente bem, quando estamos dentro de um módulo. Vamos cobrir módulos no artigo <info:modules-intro>. | |
| Em navegadores modernos, o `await` em nível superior funciona perfeitamente bem, quando estamos dentro de um módulo. Vamos abordar módulos no artigo <info:modules-intro>. |
Contributor
Author
|
Obrigado, @gabifs! Apliquei tudo: corrigi "resolve"→"rejeita" (batendo com o código), "travar"→"ser encerrado", o falso cognato "eventualmente"→"por fim", "wrapper"→"função que envolve" (2x), "cai através"→"algo que não foi tratado", concordância verbal "haveria"→"teremos", e "cobrir"→"abordar". |
Open
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Tradução do artigo "Async/await" para o português, incluindo os 4 exercícios.
Conforme comentado na #1.