[Encontro GURU-SP e ELUG] Ruby on Fails - Tratamento de erros de maneira efetiva e com convenções do Rails

Transcript

1. Ruby on Fails Tratamento de erros de maneira efetiva e com convenções do Rails @talyssonoc | @codeminer42
2. Talysson Oliveira Arquiteto de software & Chief Learning Officer na Codeminer42 @talyssonoc beacons.ai/talyssonoc
3. codeminer42.com @codeminer42
4. Exceções e erros Anti-padrões comuns para tratamento de erro Tratamento de erros de maneira efetiva
5. Exceções e erros Anti-padrões comuns para tratamento de erro Tratamento de erros de maneira efetiva
6. Exceções e erros - Exceções são um mecanismo para expressar caminhos infelizes - Quando usamos esse mecanismo em cenários em que podemos nos recuperar da falha, chamamos de um cenário de erro - Nessa talk focaremos em erros recuperáveis: - Erros de validação - Erros de autenticação - Erros de pagamento - …
7. Exceções em Ruby - Exceções são usadas para comunicar o raise com o rescue - A classe base de todas as exceções se chama Exception - Errors geralmente são descendentes da classe StandardError
8. Hierarquia de classes de erro em Ruby padrão do rescue padrão do raise
9. Exceções e erros Anti-padrões comuns para tratamento de erro Tratamento de erros de maneira efetiva
10. Se recuperar de Exception "só pra garantir" - A classe Exception é muito genérica, mesmo que "só pra garantir" - Não devemos tratar erros para estados que são inerentemente inválidos e/ou que não podemos fazer nada a respeito - Tentar se recuperar de Exception sem uma razão muito boa torna seu código menos seguro
11. O que acontece se usarmos o rescue com essa classe? Hierarquia de classes de erro em Ruby
12. O que acontece se usarmos o rescue com essa classe? Esse é o erro: arquivo_com_erro_de_sintaxe.rb:3: syntax error, unexpected end-of-input, expecting `end' or dummy end Hierarquia de classes de erro em Ruby
13. Usar erros para controle de fluxo em um mesmo contexto
14. Usar erros para controle de fluxo em um mesmo contexto - Erros e o método raise não devem ser usados onde uma condicional seria o suficiente - Isso seria semelhante a usar erros como: - Alternativas inadequadas para efeitos algébricos - Uma ação de goto - Fazer isso torna seu código mais difícil de ler e menos performático
15. ✓ ✓
16. Exceções e erros Anti-padrões comuns para tratamento de erro Tratamento de erros de maneira efetiva
17. Objetivos - Uma estratégia consistente e pragmática para tratamento de erros - Tornar os cenários de erro explícitos - Prover informações o suficiente para o call-site (o lado que chama o código que pode falhar) tomar decisões - Seguir convenções e o Rails-way
18. Seja intencional
19. Seja intencional - Não tente "adivinhar" os cenários de erro, descubra eles - Antes de escrever o código, projete ele considerando os caminhos infelizes do seu fluxo - Erros existem para se comunicar com o call-site - Só trate cenários que você pode se recuperar de maneira adequada
20. Item indisponível Fraude detectada Cartão inválido Dados do pedido inválidos Serviço fora do ar Falta de memória Serviço fora do ar BD fora do ar … Saldo insuficiente
21. Item indisponível Fraude detectada Cartão inválido Dados do pedido inválidos Serviço fora do ar Falta de memória Serviço fora do ar BD fora do ar … Saldo insuficiente
22. Como expressamos estes cenários de erro no nosso código?
23. Torne os cenários de erro explícitos - Crie classes de erro que expressam o que aconteceu - Especialmente importante quando: - Um método pode falhar por mais de um motivo, ou - Você precisa adicionar mais informação sobre o erro além da mensagem - Classes de erro customizadas devem ser herdar de StandardError - Adicione métodos à essas classes para enriquecer as informações
24. Item indisponível
25. Item indisponível
26. Abstraia erros da mesma forma que você faz com lógica
27. ActiveRecord::RecordInvalid
28. "Vazamento" de tratamento de erro
29. Abstraia erros da mesma forma que você faz com lógica - Evite vazamento de abstrações erros - Do inglês "leaky abstraction" - A origem de um erro deve ser clara no call-site - Encapsule erros específicos de gems - Use o método Error#cause
30. Abstraindo erros
31. Abstraindo erros
32. Abstraindo erros
33. Sem perda de informações Perda do erro original para debugging? #<ThirdPartyFraudDetector::FraudulentCustomer @customer_id=93 @reason="Suspect transaction">
34. Use polimorfismo para deixar suas opções em aberto
36. Use polimorfismo para deixar suas opções em aberto - As vezes, precisamos tratar uma família de erros da mesma forma - Listar todos os erros manualmente quando você quer todos eles é algo propenso a erros - Você não precisa de nada extravagante pra isso, dá pra ser simples! - Use o padrão de projeto Layer Supertype quando necessário - Aqui vai um segredo: você já usa ele com Rails o tempo todo - Exemplos do padrão Layer Supertype com Rails: - ApplicationController - ApplicationRecord - ApplicationJob
38. ✓
39. Use uma estratégia centralizada
40. ✓ ✓ ✓ 🤨
41. Use uma estratégia centralizada - Não centralizar aumenta as chances de tratamento inconsistente - Especialmente importante quando sua aplicação tem várias portas de entrada: - Endpoints de API, endpoints com views, background jobs, ActionCable, … - Só usar o rescue_from não torna realmente centralizado - Tome cuidado para não centralizar demais
42. Definindo um error reporter
43. Chama o ErrorReporter#report Usando o reporter
44. Usando o reporter Reporting CheckoutService::FraudDetected - - {:controller=>#<CheckoutsController:0x00000000003b60>}
45. Reporting SomeError - - {:controller=>#<CheckoutsController:0x00000000003b60>} Reporting Sidekiq::JobRetry::Skip - SomeError - {:job=>#<RecurrentOrderJob:0x00007ffb900b1f60 @arguments=[], @job_id="[...]", [omitted]} Funciona automaticamente para cenários não tratados
46. Use boas convenções
47. Convenções - A força do Rails é proveniente de suas convenções - Infelizmente, ele não fornece convenções fortes para erros - Podemos criar as nossas próprias, seguindo o Rails-way! - Boas convenções que seguem o Rails-way devem fornecer: - Padrões seguros e confiáveis - Um jeito prático de serem quebradas quando necessário
48. Defina uma classe de erro base
49. ApplicationError é muito genérico Próximo passo?
50. Defina e use um padrão centralizado seguro Isso é uma estratégia centralizada segura
51. Quebrando uma convenção Convenção quebrada com sucesso
52. Ah, mas e as… - Estratégias para gerenciar fluxo da aplicação, como: - Result object - Railway oriented programming, Trailblazer, … - Monads - Bom, elas são ótimas! Mas… - É importante manter elas sob controle, caso contrário…
53. Original image by @ShyRyanW <https://twitter.com/ShyRyanW/status/1702730128520830994>
54. Estratégias para gerenciar fluxo da aplicação - Abstrações são boas para modelar os fluxos da sua aplicação - É impedir que elas "coloram" o seu código - Caso contrário, todo o seu código precisará saber lidar com elas - Mantenha sob controle as abstrações que representam casos de uso: - Services, operations, interactors, … - Use objetos de erros comuns em todo o resto Controllers Jobs Channels Services Operations Interactors Infraestrutura Regras de negócio (Domínio e models)
55. Pontos principais - Não use erros para controle de fluxo - Seja intencional e explícito com seus cenários de erro - Abstraia erros da mesma forma que você faz com lógica - Reduza inconsistências centralizando o tratamento de erros - Crie e siga convenções para seu projeto - Mantenha sob controle abordagens que podem afetar o código de toda a sua aplicação
56. Obrigado! @talyssonoc beacons.ai/talyssonoc @codeminer42 codeminer42.com
57. Links - Ruby Exceptions - Ruby's Exceptional Creatures - Ruby Style Guide - Error handling - Error Reporting in Rails Applications @talyssonoc beacons.ai/talyssonoc @codeminer42 codeminer42.com