mirror of
https://github.com/goldbergyoni/nodebestpractices.git
synced 2025-10-29 16:46:01 +08:00
Corrected some typos
This commit is contained in:
Douglas Mariano Valero
@ -130,7 +130,7 @@ Leia em diferentes linguagens: [**CN**](/README.chine
|
||||
|
||||
**Caso contrário:** Ao invocar algum componente, sendo incerto qual tipo de erro irá retornar - isso faz com que o tratamento de erros seja muito mais difícil. Até pior, usar tipos personalizados para descrever erros pode levar à perda de informações de erros críticos, como o stack trace!
|
||||
|
||||
🔗 [**Leia Mais: usando o objeto interno de erro**](/sections/errorhandling/useonlythebuiltinerror.md)
|
||||
🔗 [**Leia Mais: usando o objeto interno de erro**](/sections/errorhandling/useonlythebuiltinerror.brazilian-portuguese.md)
|
||||
|
||||
<br/><br/>
|
||||
|
||||
@ -140,17 +140,17 @@ Leia em diferentes linguagens: [**CN**](/README.chine
|
||||
|
||||
**Caso contrário:** Você pode sempre reiniciar o aplicativo quando um erro aparecer, mas por que derrubar aproximadamente 5000 usuários que estavam online por causa de um pequeno erro operacional previsto? O contrário também não é ideal - manter a aplicação rodando quando um problema desconhecido (erro de programação) ocorreu, pode levar para um comportamento não esperado. Diferenciá-los, permite agir com tato e aplicar uma abordagem equilibrada baseada no dado contexto.
|
||||
|
||||
🔗 [**Leia Mais: erros operacionais vs erros de programação**](/sections/errorhandling/operationalvsprogrammererror.md)
|
||||
🔗 [**Leia Mais: erros operacionais vs erros de programação**](/sections/errorhandling/operationalvsprogrammererror.brazilian-portuguese.md)
|
||||
|
||||
<br/><br/>
|
||||
|
||||
## ![✔] 2.4 Trate erros de forma centralizada, não dentro de um middleware do Express
|
||||
|
||||
**TL;DR:** A lógica de tratamento de erros, bem como email para administrador e loggin, deve ser encapsulada em um objeto dedicado e centralizado que todos os endpoints (por exemplo, middleware do Express, cron jobs, testes unitários) chamem quando um erro é recebido.
|
||||
**TL;DR:** A lógica de tratamento de erros, bem como email para administrador e registros (logs), deve ser encapsulada em um objeto dedicado e centralizado que todos os endpoints (por exemplo, middleware do Express, cron jobs, testes unitários) chamem quando um erro é recebido.
|
||||
|
||||
**Caso contrário:** Não tratar os erros em um mesmo lugar irá levar à duplicidade de código, e provavelmente, a erros tratados incorretamente.
|
||||
|
||||
🔗 [**Leia Mais: tratando erros de forma centralizada**](/sections/errorhandling/centralizedhandling.md)
|
||||
🔗 [**Leia Mais: tratando erros de forma centralizada**](/sections/errorhandling/centralizedhandling.brazilian-portuguese.md)
|
||||
|
||||
<br/><br/>
|
||||
|
||||
@ -160,7 +160,7 @@ Leia em diferentes linguagens: [**CN**](/README.chine
|
||||
|
||||
**Caso contrário:** Um cliente de uma API pode decidir travar e reiniciar, apenas pelo motivo de ter recebido de volta um erro que não conseguiu entender. Nota: o visitante de sua API pode ser você (muito comum em um ambiente de microsserviço).
|
||||
|
||||
🔗 [**Leia Mais: documentando erros no Swagger**](/sections/errorhandling/documentingusingswagger.md)
|
||||
🔗 [**Leia Mais: documentando erros no Swagger**](/sections/errorhandling/documentingusingswagger.brazilian-portuguese.md)
|
||||
|
||||
<br/><br/>
|
||||
|
||||
@ -170,7 +170,7 @@ Leia em diferentes linguagens: [**CN**](/README.chine
|
||||
|
||||
**Caso contrário:** Quando uma exceção desconhecida é lançada, algum objeto pode estar com defeito (por exemplo, um emissor de evento que é usado globalmente e não dispara mais eventos devido a alguma falha interna) e todas as requisições futuras podem falhar ou se comportar loucamente.
|
||||
|
||||
🔗 [**Leia Mais: finalizando o processo**](/sections/errorhandling/shuttingtheprocess.md)
|
||||
🔗 [**Leia Mais: finalizando o processo**](/sections/errorhandling/shuttingtheprocess.brazilian-portuguese.md)
|
||||
|
||||
<br/><br/>
|
||||
|
||||
@ -180,7 +180,7 @@ Leia em diferentes linguagens: [**CN**](/README.chine
|
||||
|
||||
**Caso contrário:** Ficar procurando através de console.logs ou manualmente em arquivos de texto confusos sem utilizar ferramentas de consulta ou um visualizador de log decente, pode mantê-lo ocupado até tarde.
|
||||
|
||||
🔗 [**Leia Mais: usando um logger maduro**](/sections/errorhandling/usematurelogger.md)
|
||||
🔗 [**Leia Mais: usando um logger maduro**](/sections/errorhandling/usematurelogger.brazilian-portuguese.md)
|
||||
|
||||
<br/><br/>
|
||||
|
||||
@ -190,7 +190,7 @@ Leia em diferentes linguagens: [**CN**](/README.chine
|
||||
|
||||
**Caso contrário:** Sem testes, seja automático ou manual, não podemos confiar em nosso código para retornar os erros certos. Sem erros significantes, não há tratamento de erros.
|
||||
|
||||
🔗 [**Leia Mais: fluxos de testes de erros**](/sections/errorhandling/testingerrorflows.md)
|
||||
🔗 [**Leia Mais: fluxos de testes de erros**](/sections/errorhandling/testingerrorflows.brazilian-portuguese.md)
|
||||
|
||||
<br/><br/>
|
||||
|
||||
@ -200,7 +200,7 @@ Leia em diferentes linguagens: [**CN**](/README.chine
|
||||
|
||||
**Caso contrário:** Você pode gastar muito esforço medindo o desempenho e os tempos de inatividade (downtime) da API. Provavelmente, você nunca saberá quais são suas partes de código mais lentas no cenário real e como elas afetam o UX.
|
||||
|
||||
🔗 [**Leia Mais: usando APM**](/sections/errorhandling/apmproducts.md)
|
||||
🔗 [**Leia Mais: usando APM**](/sections/errorhandling/apmproducts.brazilian-portuguese.md)
|
||||
|
||||
<br/><br/>
|
||||
|
||||
@ -210,7 +210,7 @@ Leia em diferentes linguagens: [**CN**](/README.chine
|
||||
|
||||
**Caso contrário:** Seus erros serão engolidos e não vão deixar rastros. Nada para se preocupar.
|
||||
|
||||
🔗 [**Leia Mais: capturando rejeições de promises não tratadas**](/sections/errorhandling/catchunhandledpromiserejection.md)
|
||||
🔗 [**Leia Mais: capturando rejeições de promises não tratadas**](/sections/errorhandling/catchunhandledpromiserejection.brazilian-portuguese.md)
|
||||
|
||||
<br/><br/>
|
||||
|
||||
@ -220,7 +220,7 @@ Leia em diferentes linguagens: [**CN**](/README.chine
|
||||
|
||||
**Caso contrário:** Considere isto: sua função espera receber um “Desconto” como argumento numérico que foi esquecido de passar. Mais adiante, seu código verifica se Desconto!=0 (valor do desconto permitido é maior que zero). Depois, irá permitir que o usuário desfrute de um desconto. Meu Deus, que baita bug. Entendeu?
|
||||
|
||||
🔗 [**Leia Mais: falhando rápido**](/sections/errorhandling/failfast.md)
|
||||
🔗 [**Leia Mais: falhando rápido**](/sections/errorhandling/failfast.brazilian-portuguese.md)
|
||||
|
||||
<br/><br/><br/>
|
||||
|
||||
|
||||
@ -5,7 +5,7 @@
|
||||
|
||||
Exceção != Erro. O tratamento de erros tradicional pressupõe a existência de Exceção, mas os erros de aplicativo podem vir na forma de caminhos de código lento, tempo de inatividade (downtime) da API, falta de recursos computacionais e muito mais. É aqui que os produtos APM são úteis, pois permitem detectar uma ampla variedade de problemas "enterrados" de forma proativa e com uma configuração mínima. Entre os recursos comuns dos produtos APM estão, por exemplo, alertas quando a API HTTP retorna erros, detecta quando o tempo de resposta da API cai abaixo de um limite, detecção de 'códigos suspeitos', formas de monitorar recursos do servidor, painel de inteligência operacional com métricas de TI e muitos outros recursos úteis. A maioria dos fornecedores oferece um plano gratuito.
|
||||
|
||||
### Wikipedia sobre APM
|
||||
### Wikipédia sobre APM
|
||||
|
||||
Nos campos de tecnologia da informação e gerenciamento de sistemas, o Application Performance Management (APM) é o monitoramento e gerenciamento de desempenho e disponibilidade de aplicativos de software. O APM se esforça para detectar e diagnosticar problemas complexos de desempenho do aplicativo para manter um nível esperado de serviço. APM é "a tradução de métricas de TI em significado de negócios ([i.e.] value)". Principais produtos e segmentos.
|
||||
|
||||
|
||||
@ -7,8 +7,7 @@ Exception != Error. Traditional error handling assumes the existence of Exceptio
|
||||
|
||||
### Wikipedia about APM
|
||||
|
||||
In the fields of information technology and systems management, Application Performance Management (APM) is the monitoring and management of performance and availability of software applications. APM strives to detect and diagnose complex application performance problems to maintain an expected level of service. APM is “the translation of IT metrics into business meaning ([i.e.] value)
|
||||
Major products and segments
|
||||
In the fields of information technology and systems management, Application Performance Management (APM) is the monitoring and management of performance and availability of software applications. APM strives to detect and diagnose complex application performance problems to maintain an expected level of service. APM is “the translation of IT metrics into business meaning ([i.e.] value)". Major products and segments.
|
||||
|
||||
### Understanding the APM marketplace
|
||||
|
||||
|
||||
@ -8,7 +8,7 @@ Distinguir os dois tipos de erros a seguir minimizará o tempo de inatividade do
|
||||
|
||||
```javascript
|
||||
// marcando um objeto de erro como operacional
|
||||
const myError = new Error("How can I add new product when no value provided?");
|
||||
const myError = new Error("Como posso adicionar um novo produto quando nenhum valor é fornecido?");
|
||||
myError.isOperational = true;
|
||||
|
||||
// ou se você estiver usando alguma fábrica centralizada de erros (veja outros exemplos no marcador "Use somente o objeto Error interno")
|
||||
@ -22,7 +22,7 @@ class AppError {
|
||||
}
|
||||
};
|
||||
|
||||
throw new AppError(errorManagement.commonErrors.InvalidInput, "Describe here what happened", true);
|
||||
throw new AppError(errorManagement.commonErrors.InvalidInput, "Descreva aqui o que aconteceu", true);
|
||||
|
||||
```
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
### One Paragraph Explainer
|
||||
|
||||
Somewhere within your code, an error handler object is responsible for deciding how to proceed when an error is thrown – if the error is trusted (i.e. operational error, see further explanation within best practice #3) then writing to log file might be enough. Things get hairy if the error is not familiar – this means that some component might be in a faulty state and all future requests are subject to failure. For example, assuming a singleton, stateful token issuer service that threw an exception and lost its state – from now it might behave unexpectedly and cause all requests to fail. Under this scenario, kill the process and use a ‘Restarter tool’ (like Forever, PM2, etc) to start over with a clean slate.
|
||||
Somewhere within your code, an error handler object is responsible for deciding how to proceed when an error is thrown – if the error is trusted (i.e. operational error, see further explanation within best practice #3) then writing to log file might be enough. Things get hairy if the error is not familiar – this means that some component might be in a faulty state and all future requests are subject to failure. For example, assuming a singleton, stateful token issuer service that threw an exception and lost its state – from now it might behave unexpectedly and cause all requests to fail. Under this scenario, kill the process and use a ‘Restarter tool’ (like Forever, PM2, etc) to start over with a clean state.
|
||||
|
||||
### Code example: deciding whether to crash
|
||||
|
||||
|
||||
@ -9,7 +9,7 @@ A natureza permissiva do JS junto com sua variedade de opções de fluxo de cód
|
||||
```javascript
|
||||
// jogando um Error de uma função típica, seja síncrona ou assíncrona
|
||||
if(!productToAdd)
|
||||
throw new Error("How can I add new product when no value provided?");
|
||||
throw new Error("Como posso adicionar um novo produto quando nenhum valor é fornecido?");
|
||||
|
||||
// 'jogando' um Error de um EventEmitter
|
||||
const myEmitter = new MyEmitter();
|
||||
@ -20,7 +20,7 @@ const addProduct = async (productToAdd) => {
|
||||
try {
|
||||
const existingProduct = await DAL.getProduct(productToAdd.id);
|
||||
if (existingProduct !== null) {
|
||||
throw new Error("Product already exists!");
|
||||
throw new Error("O produto já existe!");
|
||||
}
|
||||
} catch (err) {
|
||||
// ...
|
||||
@ -33,7 +33,7 @@ const addProduct = async (productToAdd) => {
|
||||
```javascript
|
||||
// lançar uma string não possui informações de rastreamento de stack e outras propriedades de dados importantes
|
||||
if(!productToAdd)
|
||||
throw ("How can I add new product when no value provided?");
|
||||
throw ("Como posso adicionar um novo produto quando nenhum valor é fornecido?");
|
||||
```
|
||||
|
||||
### Exemplo de código - fazendo isso ainda melhor
|
||||
@ -53,7 +53,7 @@ module.exports.AppError = AppError;
|
||||
|
||||
// cliente jogando uma exceção
|
||||
if(user == null)
|
||||
throw new AppError(commonErrors.resourceNotFound, commonHTTPErrors.notFound, "further explanation", true)
|
||||
throw new AppError(commonErrors.resourceNotFound, commonHTTPErrors.notFound, "mais explicações", true)
|
||||
```
|
||||
|
||||
### Citação de Blog: "Não vejo o valor em ter vários tipos diferentes"
|
||||
|
||||
Reference in New Issue
Block a user