DEV Community

Criando Exceptions para impressionar no Teste Técnico

Daniel Reis on October 10, 2023

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...

Read full post

Lucca Mabel • Oct 10 '23

Exception precisam contar minimamente uma história pro usuário ou pro desenvolvedor do quê tá acontecendo.

Acho que nunca havia olhado para as Exceptions dessa forma, e realmente isso muda tudo.

Excelente artigo, ótimo material para estudar!!!

LeandroSeg • Oct 12 '23

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.

Douglas Fernandes • Oct 11 '23

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:

LeandroSeg • Oct 12 '23

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.

Felipe Martins • Oct 11 '23

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:

Teorico: código HTTP está relacionado ao protocolo de comuinicação. Portanto, este deve existir apenas na cada de apresentação ou interface de usário (aquele User Interface do DDD).
Prático: dependendo da origem da chamada do endpoint ou do cliente que irá chamar este método, o erro PlayerInventoryException::itemNotFound poderá ter significados diferentes e nem sempre o 403 é 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:

class IradoController
{
    public function equipItem(Request $request): Response
    {
        try {
            // chamada plau
        } catch (PlayerInventoryException) {
            return new Response(403, 'Ação não permitida');
        }

        // uau! Nao teve erro
    }

    public function showItemDetails(Request $request): Response
    {
        try {
            // chamada chata
        } catch (PlayerInventoryException) {
            return new Response(404, 'Item não encontrado');
        }

        // uau! Nao teve erro
    }
}

Parabéns de nv e continue publicando conteúdo de qualidade!

Cherry Ramatis • Oct 10 '23

foda demais o conteudo, ate salvei pra ler com calma e adaptar o conhecimento pra ruby

Nicolas Evangelista • Oct 10 '23

Excelente artigo, parabéns pelo conteúdo! Obrigado por compartilhar!

Alicia Marianne • Oct 10 '23

Muito bom o artigo, claro e didático.

Canhassi • Oct 10 '23

Muito bom!

Victor Farias • Jun 11 '24

Que conteúdo bom! Valeu demais, espero usar de referência pra meus testes techs!

Renan Vidal Rodrigues • Oct 10 '23

Ótimo artigo!

guto • Oct 10 '23

Simplesmente incrível! Muito bom artigo!

Lucas • Oct 10 '23 • Edited

Mamma mia, que artigo 🤌

Agradeço pelo post, muito bom aprender sobre essas melhorias

JefteMartins • Oct 10 '23

Excelente artigo!

Clerivaldo Junior • Oct 11 '23

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!

Sergio Gomes • Oct 10 '23

Excelente artigo!!!

HLAM • Oct 11 '23

Parabéns pelo artigo, muito simples de entender e esclarece muitos pontos importantes!

Xossy • Nov 9 '23 • Edited

Já vinha procurando esse tipo de conteúdo faz tempo, sempre tratei os erros
forma genérica. parabéns pelo conteúdo.

Keit Oliveira • Oct 10 '23

top demais! 👏🏻👏🏻

Larissa de Oliveira • Oct 11 '23

Didática incrível 👏👏👏

Walter Santos • Oct 11 '23

Excelente, muito obrigado!

Breno Almeida • Oct 11 '23

Conteúdo muito bom, sendo objetivo e com uma didática excelente. Já compartilhando com os colegas.

Jandelson Oliveira • Oct 11 '23

Artigo sensacional sobre as exceptions.

Gustavo de Camargo Campos • Oct 24 '23

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?

Daniel Reis • Oct 24 '23

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...

Luiz • Oct 23 '23

Daniel, sensacional! Mas, por ser método estático não ficaria um pouco mais complicado pra testar?