Importante

Você está vendo a versão anterior da nova experiência da Alura que estamos preparando para você. Em breve, ela ganha uma identidade visual novinha totalmente pensada em potencializar seus estudos!

1
resposta

Abordagem diferente para tratar o erro 404 na controller

Pensando um pouco mais no retorno e num futuro associar uma estrutura no response da chamada da API DetalharMedico, pensei em uma abordagem um pouco diferente na controller. Em vez de utilizar o getReferenceById, substituir por findById. Por que usar? Uma vez que a associamos o getRerence, ele não vai no DTO consultar. Lendo a documentação do spring, ele apenas rejeita a requisição e devolve um Exception.

"Returns a reference to the entity with the given identifier. Depending on how the JPA persistence provider is implemented this is very likely to always return an instance and throw an EntityNotFoundException on first access. Some of them will reject invalid identifiers immediately."

Como falei acima, o metodo abaixo, junto com uma classe DTO e uma nova função para mapear o erro, alinhada para retorno e estruturada para mostrar o body no response, achei interessante utilizar o findById que vai na tabela e busca o dado, caso nao encontre, posso tratar com erro e uma mensagem, por exemplo, "Medico nao encontrado"

public ResponseEntity detalhar(@PathVariable Long id) {
return repository.findById(id)
.map(medico -> ResponseEntity.ok(new DadosDetalhamentoMedico(medico)))
.orElse(ResponseEntity.notFound().build());
}

1 resposta

Olá Caio.
Tudo bem?
Sua observação faz bastante sentido. Ao utilizar findById(), você obtém um fluxo mais explícito para tratar registros inexistentes, evitando depender do comportamento do proxy retornado pelo getReferenceById() e da eventual ocorrência de uma EntityNotFoundException.
A solução proposta também melhora a legibilidade do código, pois deixa claro o que acontece em cada cenário: quando o médico é encontrado, os dados são retornados; quando não é encontrado, a API responde adequadamente com um 404 Not Found.
Além disso, pensar desde já em uma estrutura padronizada para respostas de erro é uma excelente prática, especialmente em APIs que tendem a crescer e ser consumidas por diferentes clientes. Isso facilita a manutenção, o monitoramento e a integração com outras aplicações.
Parabéns pela análise crítica e por buscar alternativas além do conteúdo apresentado. Esse olhar para robustez, experiência do consumidor da API e evolução futura do projeto é uma característica muito valorizada no desenvolvimento de software.
Avise qualquer dúvida.
Bons estudos.