1
resposta

[Sugestão] Alternativa para o método obterPorId usando orElseThrow e constructor do DTO

Durante a aula, as instrutoras decidiram por fazer o método "obterPorId" da seguinte forma:

public SerieDTO obterPorId(Long id) {
        Optional<Serie> serie = serieRepository.findById(id);

        if (serie.isPresent()) {
            Serie s = serie.get();
            return new SerieDTO(s.getId(), s.getTitulo(), s.getTotalTemporadas(), s.getAvaliacao(), s.getGenero(), s.getAtores(), s.getPoster(), s.getSinopse());
        }

        return null;
    }

Porém, como forma alternativa, decidi implementar da seguinte forma:

public SerieDTO obterSeriePeloId(Long id) {
        Serie serie = serieRepository.findById(id).orElseThrow(() -> new RuntimeException("Serie nao encontrada."));
        return new SerieDTO(serie);
    }

No meu caso, o SerieDTO já possui um construtor que recebe um objeto Serie, achei que essa abordagem deixou o codigo mais limpo, alem de retornar uma Exception no lugar de Null. Gostaria de saber outras opiniões: Há alguma vantagem ou desvantagem que eu talvez não tenha considerado? Vale a pena usar orElseThrow ou em algum caso seria melhor retornar null?

1 resposta

Oi Matheus! Como vai?

Sua abordagem de usar orElseThrow é uma ótima maneira de tornar o código mais limpo e seguro. Ao lançar uma exceção quando a série não é encontrada, você está evitando o retorno de null, que pode levar a NullPointerExceptions em outras partes do código se não for tratado adequadamente.

Aqui estão algumas considerações sobre as duas abordagens:

Vantagens de usar orElseThrow:

  1. Clareza e Segurança: Lançar uma exceção deixa claro que a ausência de uma série é um estado excepcional que precisa ser tratado, em vez de apenas retornar null.
  2. Redução de Código: Usar um construtor que aceita um objeto Serie torna o código mais conciso e fácil de manter.
  3. Facilidade de Depuração: Exceções fornecem stack traces que podem ajudar a identificar rapidamente onde e por que algo deu errado.

Desvantagens Potenciais:

  1. Tratamento de Exceções: Você precisará garantir que a exceção seja tratada adequadamente em algum lugar do seu fluxo de aplicação, para que o usuário final receba uma mensagem amigável ou um comportamento apropriado.
  2. Impacto na Performance: Embora geralmente insignificante, lançar exceções pode ter um pequeno impacto na performance se ocorrer com frequência.

Quando retornar null pode ser útil:

  1. Compatibilidade com Código Existente: Se o restante do seu sistema já está configurado para lidar com null de maneira segura e eficaz, pode ser mais simples continuar com essa abordagem.
  2. Simplicidade em Aplicações Menores: Em aplicações menores ou menos críticas, onde o tratamento de exceções pode ser considerado um overhead desnecessário, retornar null pode ser aceitável.

No seu caso, a escolha de usar orElseThrow parece uma boa prática, especialmente se você está buscando um código mais robusto e fácil de manter. Apenas se certifique de que as exceções são tratadas adequadamente no controlador ou em outro lugar para fornecer uma boa experiência ao usuário.

Espero ter ajudado e bons estudos!

Caso este post tenha lhe ajudado, por favor, marcar como solucionado ✓.