Skip to content

Custom errors, extending Error - #474

Open
diogoosz wants to merge 1 commit into
javascript-tutorial:masterfrom
diogoosz:translate-custom-errors
Open

diogoosz wants to merge 1 commit into
javascript-tutorial:masterfrom
diogoosz:translate-custom-errors

Conversation

@diogoosz

@diogoosz diogoosz commented Nov 8, 2026

Copy link
Copy Markdown
Contributor

Tradução do artigo "Custom errors, extending Error" para o português, incluindo o exercício.

Conforme comentado na #1.

🤖 Generated with Claude Code

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
```

Internally, we'll use `JSON.parse`. If it receives malformed `json`, then it throws `SyntaxError`. But even if `json` is syntactically correct, that doesn't mean that it's a valid user, right? It may miss the necessary data. For instance, it may not have `name` and `age` properties that are essential for our users.
Internamente, vamos usar `JSON.parse`. Se ele receber um `json` malformado, então lança `SyntaxError`. Mas mesmo que o `json` seja sintaticamente correto, isso não significa que seja um usuário válido, certo? Pode faltar os dados necessários. Por exemplo, pode não ter as propriedades `name` e `age`, que são essenciais para nossos usuários.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Concordância: "Pode faltar os dados necessários" — sujeito é plural ("os dados"), então o verbo deve ir pro plural: "Podem faltar os dados necessários".

Também é importante que, se o `catch` encontrar um erro desconhecido, ele o relance na linha `(**)`. O bloco `catch` só sabe tratar erros de validação e de sintaxe; outros tipos (causados por um erro de digitação no código ou outros motivos desconhecidos) devem passar adiante.

## Further inheritance
## Mais herança

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Mais herança" soa estranho como título para "Further inheritance". Sugestão: "Herança adicional" ou "Aprofundando a herança".

A nova classe `PropertyRequiredError` é fácil de usar: só precisamos passar o nome da propriedade: `new PropertyRequiredError(property)`. A `message` legível para humanos é gerada pelo construtor.

Please note that `this.name` in `PropertyRequiredError` constructor is again assigned manually. That may become a bit tedious -- to assign `this.name = <class name>` in every custom error class. We can avoid it by making our own "basic error" class that assigns `this.name = this.constructor.name`. And then inherit all our custom errors from it.
Repare que o `this.name` no construtor de `PropertyRequiredError` é, de novo, atribuído manualmente. Isso pode ficar meio repetitivo -- atribuir `this.name = <nome da classe>` em cada classe de erro personalizada. Podemos evitar isso criando nossa própria classe "básica de erro" que atribui `this.name = this.constructor.name`. E então herdar todos os nossos erros personalizados dela.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"classe "básica de erro"" é uma tradução literal meio truncada de "basic error" class. Sugestão: "nossa própria classe de erro "base"".

Muitas vezes a resposta é "Não": gostaríamos de estar "um nível acima de tudo isso". Só queremos saber se houve um "erro de leitura de dados" -- o motivo exato pelo qual aconteceu, muitas vezes, é irrelevante (a mensagem de erro já descreve isso). Ou, melhor ainda, gostaríamos de ter uma forma de obter os detalhes do erro, mas só se precisarmos.

The technique that we describe here is called "wrapping exceptions".
A técnica que descrevemos aqui é chamada de "empacotamento de exceções" (*wrapping exceptions*).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Terminologia: no resto do repo, "wrapper/wrapping" foi traduzido como "encapsular/encapsuladora" (ex.: 1-js/99-js-misc/01-proxy/article.md). Considerar "encapsulamento de exceções" aqui e na linha 324 pra manter consistência — ou manter "empacotamento", mas aí de forma consciente.

alert(e);
// Original error: SyntaxError: Unexpected token b in JSON at position 1
alert("Original error: " + e.cause);
// Erro original: SyntaxError: Unexpected token b in JSON at position 1

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pré-existente (não introduzido pela tradução): a mensagem Unexpected token b in JSON at position 1 está desatualizada — V8 moderno mostra Unexpected token 'b', "{bad json}" is not valid JSON. O leitor que rodar o exemplo verá texto diferente do comentário. Opcional ajustar.

Exemplo de uso:

```js
let err = new FormatError("formatting error");

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Código do exemplo ficou em inglês: na linha 21, // true (because inherits from SyntaxError) → sugestão // true (porque herda de SyntaxError). Também vale considerar traduzir a string "formatting error" (linhas 14/16 e solution.md), já que o artigo traduz as mensagens dos exemplos ("Opa!", "Faltando o campo: ..."). Se traduzir, atualizar o solution.md junto.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants