O tratamento de erros em Type/JavaScript é um tópico que não recebe a importância que merece. É crucial para a longevidade de qualquer projeto detectar e registrar erros.

À medida que comecei a trabalhar mais com TypeScript ao longo dos anos, comecei a perceber que realmente não entendia o tratamento de erros. Muitas vezes eu me deparava com este problema:

erroré type unknown, portanto, não podemos executar nenhuma ação erroraté que o convertamos em um novo tipo ou restrinja o tipo . A resposta correta é restringir o tipo e veremos como fazer isso, mas por que isso é necessário?

Em JavaScript, quase tudo pode ser lançado:

Portanto, o erro realmente detectado é desconhecido. Porém, existem maneiras de lidar com erros de forma limpa com o TypeScript e, ao longo dos anos, desenvolvi um padrão de design que realmente gosto de usar para me ajudar a fazer exatamente isso.

Primeiro, o básico sobre erros em JavaScript

Tipos de erros em JavaScript

Existem muitos tipos de erros em JavaScript , mas os mais comuns são:

• ReferenceError— O código referenciou uma variável que não existe.
• TypeError— Um valor não era do tipo esperado.
• SyntaxError— O código era sintaticamente inválido.

Há momentos em que você deve lançar um erro manualmente. Por exemplo, você pode ter algum código que depende de um valor retornado de uma chamada de função, mas existe a possibilidade de o valor ser undefined, ou pelo menos o TypeScript acredita que existe. Neste exemplo, lançar é a melhor solução para restringir o userque é retornado.

Capturando erros

Uma vez que um erro é lançado, ele irá borbulhar na pilha de chamadas até ser pego em uma instrução try/ . Quando o código executado dentro de um bloco gerar um erro, ele será “capturado” no bloco. O erro pode se originar de uma função aninhada dentro de uma função e irá borbulhar até ser detectado.catchtrycatch

Limitando o tipo de erro

Uma vez capturado, pode ser útil verificar o tipo de erro que foi gerado. Isso nos permite restringir o tipo de unknown, para um tipo específico com o qual podemos interagir. Podemos fazer isso com instanceof.

Chega do básico, vamos ver o padrão de projeto

Em meu projeto mais recente, agrupei meu código por domínios em diretórios denominados Recursos. Examinarei essa arquitetura em detalhes em outro post, mas TL;DR é que um diretório de recurso contém código para um determinado domínio. Ele pode conter componentes relacionados, ganchos, tipos, erros e muito mais. O que nos interessa neste post são os erros. Cada diretório de recurso contém um errors.tsarquivo onde defino uma classe de erro personalizada para o respectivo domínio.

Criando um tipo de erro personalizado

No meu errors.tsarquivo eu exporto um arquivo class. Eu mantenho um tipo de união para os nomes em potencial, o que adiciona um bom intellisense e segurança de tipo. A classe estende o objeto Error, que permite que um rastreamento de pilha seja inserido (para a maioria dos tempos de execução JS).

Lançando um erro personalizado

Quando um novo erro é instanciado, o valor do nome tem intellisense e deve ser um dos nomes definidos no tipo de união.

Capturando um erro personalizado

Quando o erro é detectado, podemos restringir o tipo de erro usando instanceof.Uma vez reduzido, error.namenos dá intellisense. Neste ponto, podemos executar a lógica com base no nome do erro que foi lançado. Neste exemplo, o PROJECT_LIMIT_REACHEDerro é aquele que queremos mostrar ao usuário e fornecemos uma mensagem especificamente para ser renderizada para o usuário.

Fazendo uma base de erro reutilizável

Como tenho muitos errors.tsarquivos, quero garantir que meu código permaneça DRY. O único código dinâmico em nossa classe é o tipo de união de nomes. Então eu crio uma ErrorBaseclasse, que aceita um genérico que é usado como tipo de nome.

Agora, quando crio uma nova classe de erro personalizada, posso estender essa base e tudo o que preciso fazer é fornecer o tipo de união dos nomes disponíveis.

Conclusão

Eu realmente gosto desse padrão de design e, como resultado, meu código é muito mais fácil de manter. Lembre-se de que lidar com erros é apenas parte de um aplicativo bem mantido; outra etapa importante é registrar os erros usando algo como Sentry .

Espero que você tenha aprendido algo novo e, se quiser aprender mais, siga-me aqui e no Twitter @Kolbysisk .