Exceptions sempre vai ser um assunto constante quando o tópico for Orientação à Objetos e hoje vamos descobrir como criá-las como um artesão de sof...
For further actions, you may consider blocking this person and/or reporting abuse
Daniel Reis on October 10, 2023
For further actions, you may consider blocking this person and/or reporting abuse
Acho que nunca havia olhado para as Exceptions dessa forma, e realmente isso muda tudo.
Excelente artigo, ótimo material para estudar!!!
Eu entendi a ideia, ela parece que deixa as coisas mais claras, porém isso aumenta o número de códigos que vão tratar as exceptions, isso pode gerar um montão de código que você vai precisar dar manutenção quando as regras mudarem.
Eu faço diferente, crio um repositório de mensagens exceptions (ou Resources) e depois uso as referência para dispará-las de dentro dos objetos de negócios, sem mais código envolvido, já que são os objetos de negócios que sabem o que deu errado e eles devem entregar as informações para as camadas superiores de uma forma padrão. A simplicidade às vezes é melhor do que mais código envolvido e mais acoplamentos entre classes ou mais funções.
Talvez sua ideia seja mais aplicável a aplicações onde determinar o que está ocorrendo dentro de uma regra de negócio é complexo e você queira isolar tais regras.
Mas ótimo artigo e parabéns.
Excelente post amigo!! Se me permite um pitaco... Um tempo atrás li sobre o uso abusivo de try catch em desfavor ao uso de lógica com base em condicionais e o resultado é que blocos try catch tornam seu código lento (e caro) e, por este motivo, é desencorajado o uso excessivo salvo guardo ocasiões em que não se sabe qual tratativa realizar (casos desconhecidos pela sua lógica). Deixo aqui dois links úteis para levar em consideração quando estiver construindo alguma solução e estiver em dúvida sobre o uso de try catch ou if else:
uso excessivo de try catch é derivado de um mal projeto, a ideia base do try-catch é você reduzir o seu uso a lugares onde ele possa interceptar tudo que acontece embaixo do capô, evitando assim que aplicações buguem com CTD sem que nenhum rastreamento seja possível.
Evitar o uso de IFs é bom, adiciona complexidade ao código e pode gerar mais dor de cabeça do que resolver as coisas.
Parabéns pelo conteúdo de qualidade :)
Gostaria de apenas dar um feedback ou, talvez, mais um passo na refatoracao/evolucao das excecoes do exemplo: não é uma boa ideia colocar o código HTTP dentro das exceções de domínio/negócio.
Aqui vão motivos:
PlayerInventoryException::itemNotFoundpoderá ter significados diferentes e nem sempre o403é o mais apropriado. Portanto a tradução do erro de domínio/negócio para um erro de protocolo deve ser feita na camada mais externa.Aqui uma ideia de código:
Parabéns de nv e continue publicando conteúdo de qualidade!
foda demais o conteudo, ate salvei pra ler com calma e adaptar o conhecimento pra ruby
Simplesmente incrível! Muito bom artigo!
Excelente artigo, parabéns pelo conteúdo! Obrigado por compartilhar!
Muito massa aprender a flexibilidade de uma exception, achava que era 'um tipo de erro com algo mais', e de quebra aprender Factory. Gradesso demais pelo artigo primo!
Mamma mia, que artigo 🤌
Agradeço pelo post, muito bom aprender sobre essas melhorias
Ótimo artigo!
Excelente artigo!
Muito bom!
Que conteúdo bom! Valeu demais, espero usar de referência pra meus testes techs!
Muito bom o artigo, claro e didático.
Artigo sensacional sobre as exceptions.
Parabéns pelo artigo, muito simples de entender e esclarece muitos pontos importantes!
Didática incrível 👏👏👏
top demais! 👏🏻👏🏻
Excelente artigo!!!
Excelente, muito obrigado!
Conteúdo muito bom, sendo objetivo e com uma didática excelente. Já compartilhando com os colegas.
Já vinha procurando esse tipo de conteúdo faz tempo, sempre tratei os erros
forma genérica. parabéns pelo conteúdo.
Muito bom primo, parabéns pelo conteúdo.
Queria apenas perguntar, se não caberia criar uma classe com propriedades estáticas dos códigos HTTP que vão ser usados, pois, inserir os códigos diretamente não seria o famigerado magic number?
Sim, e eu gosto bastante disso! Geralmente uso algum componente da framework do Symfony ou Laravel da vida pra não ter que criar na mão...
Daniel, sensacional! Mas, por ser método estático não ficaria um pouco mais complicado pra testar?