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
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::itemNotFound
poderá 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
Que conteúdo bom! Valeu demais, espero usar de referência pra meus testes techs!
Muito bom o artigo, claro e didático.
Muito bom!
Simplesmente incrível! Muito bom artigo!
Excelente artigo, parabéns pelo conteúdo! Obrigado por compartilhar!
Mamma mia, que artigo 🤌
Agradeço pelo post, muito bom aprender sobre essas melhorias
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!
Excelente artigo!
Ótimo artigo!
top demais! 👏🏻👏🏻
Já venho procurando esse tipo de conteúdo faz tempo. sempre tratei os erros
forma genérica. parabéns pelo conteúdo.
Conteúdo muito bom, sendo objetivo e com uma didática excelente. Já compartilhando com os colegas.
Artigo sensacional sobre as exceptions.
Didática incrível 👏👏👏
Excelente, muito obrigado!
Parabéns pelo artigo, muito simples de entender e esclarece muitos pontos importantes!
Excelente artigo!!!
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?