Error Handler

[diogosalmeida]

Cria uma classe de error handler

[guilima]

Tem um exemplo para me ajudar? Fiquei interessado.

Hoje apenas apresento o erro com o minimo que meu conhecimento permite try... catch ratueira

[diogosalmeida]

Você cria uma classe que faz com que sua aplicação consiga logar os errors e criar estratégias de como se recuperar

https://www.npmjs.com/package/hystrixjs

https://www.joyent.com/node-js/production/design/errors

https://www.npmjs.com/package/errorhandler

https://stackoverflow.com/questions/7310521/node-js-best-practice-exception-handling

https://www.npmjs.com/package/logger

https://stackify.com/node-js-logging/

[diogosalmeida]

Esse é um principio fundamental da padronização de microserviços

[guilima]

Nada como o tempo pra rever algumas ideias. Acabei me deparando com o texto abaixo:

Ruben has several suggestions. First, he advises everyone to switch to using the async/await pattern of asynchronous code execution, which was introduced in Node 12. This allows errors to provide an async stack trace, which is more helpful in diagnosing errors than the obfuscated errors that come from promises. Second, he advises teams not to simply try-catch and rethrow errors. It's far more beneficial to abstract errors into individual classes (NotFoundError, NotPermittedError, etc), because it allows the programmer to identify immediately from the error name what went wrong.

From this abstraction, Julián and Ruben discuss its role in logging strategies. By having your errors defined as distinct classes, you can place all sorts of "generic" information in them as properties, such as the status code. With no additional programming labor, this data can be exposed in the logs for additional analysis.

Mostly, the best thing you can do is to think about errors while writing the code. For example, add tests for all the edge cases you may encounter. By investing more time upfront in the development process, you will save yourself from worries later on when the code hits production.

Exatamente o que você havia mencionado e passado de referencia @diogosalmeida . Acho que entendi melhor toda essa questão e muito graças também aos aprendizados com @wagnerssouza que esta mexendo em outro projeto top.

Quando tiver um tempo vou colocar em prática.

[diogosalmeida]

Top irmão

Em qua, 15 de jan de 2020 23:44, Guilherme Carvalho Lima < notifications@github.com> escreveu:

Nada como o tempo pra rever algumas ideias. Acabei me deparando com o texto abaixo:

Ruben has several suggestions. First, he advises everyone to switch to using the async/await pattern of asynchronous code execution, which was introduced in Node 12. This allows errors to provide an async stack trace, which is more helpful in diagnosing errors than the obfuscated errors that come from promises. Second, he advises teams not to simply try-catch and rethrow errors. It's far more beneficial to abstract errors into individual classes (NotFoundError, NotPermittedError, etc), because it allows the programmer to identify immediately from the error name what went wrong.

From this abstraction, Julián and Ruben discuss its role in logging strategies. By having your errors defined as distinct classes, you can place all sorts of "generic" information in them as properties, such as the status code. With no additional programming labor, this data can be exposed in the logs for additional analysis.

Mostly, the best thing you can do is to think about errors while writing the code. For example, add tests for all the edge cases you may encounter. By investing more time upfront in the development process, you will save yourself from worries later on when the code hits production.

Exatamente o que você havia mencionado e passado de referencia @diogosalmeida https://github.com/diogosalmeida . Acho que entendi melhor toda essa questão e muito graças também aos aprendizados com @wagnerssouza https://github.com/wagnerssouza que esta mexendo em outro projeto top.

Quando tiver um tempo vou colocar em prática.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/guilima/financial-back/issues/5?email_source=notifications&email_token=ACGGAFOI6PVAWGJ3CM4WBPDQ57CXNA5CNFSM4H37JBT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJCSAJI#issuecomment-574955557, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACGGAFMGZ2C6XC5GXO4PQJ3Q57CXNANCNFSM4H37JBTQ .