Adicionar tratamento de erro genérico (fallback de exceções não mapeadas) - #55
Conversation
- Novo record ErrorResponse para respostas padronizadas de erro - @ExceptionHandler(Exception.class) em ControllerExceptionHandler retornando 500 com mensagem genérica, sem expor stacktrace - Loga a exceção completa via @slf4j para diagnóstico no servidor - Testes cobrindo o novo handler e os handlers específicos existentes Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
🟡 Changes recommended
Os testes adicionados não validam a precedência/seleção de handlers pelo Spring na presença de um @ExceptionHandler(Exception.class), apesar de seus nomes/descrições sugerirem essa garantia.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
Este PR adiciona um fallback genérico de tratamento de exceções na camada web para evitar que erros não mapeados exponham detalhes internos ao cliente, padronizando a resposta de erro 500 e registrando o stacktrace no servidor.
Changes:
- Adiciona
ErrorResponse(String message)como payload padronizado para erros genéricos. - Inclui
@ExceptionHandler(Exception.class)noControllerExceptionHandler, retornando500 INTERNAL_SERVER_ERRORcom mensagem genérica e logando a exceção. - Cria testes unitários para o novo handler genérico e para comportamentos de handlers específicos existentes.
File summaries
| File | Description |
|---|---|
| src/main/java/com/bts/personalbudget/exception/ControllerExceptionHandler.java | Adiciona handler genérico com log via @Slf4j e resposta 500 padronizada. |
| src/main/java/com/bts/personalbudget/exception/ErrorResponse.java | Introduz record de resposta de erro genérica para não expor detalhes internos. |
| src/test/java/com/bts/personalbudget/exception/ControllerExceptionHandlerTest.java | Adiciona testes para validar payload/status do handler genérico e caminhos específicos. |
Review details
Suppressed comments (1)
src/test/java/com/bts/personalbudget/exception/ControllerExceptionHandlerTest.java:44
- Este teste também não valida a escolha do handler pelo mecanismo do Spring (prioridade entre
@ExceptionHandlermais específico vs genérico); ele só chama o método diretamente. Para evitar indicar uma garantia que o teste não cobre, renomeie a descrição/nome do teste para algo que reflita o comportamento verificado (ou troque para um teste web com MockMvc).
@DisplayName("Handler específico de MissingServletRequestParameterException deve continuar funcionando sem regressão")
void shouldStillHandleMissingParameterExceptionSpecifically() {
- Files reviewed: 3/3 changed files
- Comments generated: 1
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
🔵 Needs a closer look
Os testes atuais não exercitam a resolução real do Spring para @ExceptionHandler e há inconsistência de imports no novo teste que pode quebrar checks de formatação/estilo.
Review details
Suppressed comments (2)
Previously missed (1) — in code that hasn't changed since the last review.
src/test/java/com/bts/personalbudget/exception/ControllerExceptionHandlerTest.java:10
- Os imports não seguem o agrupamento usado nos demais testes do projeto (imports normais separados de static imports por uma linha em branco). Isso costuma causar falha em checkstyle/formatters e reduz consistência.
import com.bts.personalbudget.controller.validation.ValidationResponse;
import java.util.Map;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.MissingServletRequestParameterException;
import static org.assertj.core.api.Assertions.assertThat;
src/test/java/com/bts/personalbudget/exception/ControllerExceptionHandlerTest.java:14
- Este teste instancia o ControllerExceptionHandler diretamente e chama os métodos, então não valida o comportamento do Spring ao resolver qual
@ExceptionHandlerserá aplicado (e.g., que exceções específicas continuam tendo precedência sobre o handler genérico). Isso pode deixar passar regressões na integração real (resolver/ordem/prioridade).
private final ControllerExceptionHandler handler = new ControllerExceptionHandler();
- Files reviewed: 3/3 changed files
- Comments generated: 0 new
- Review effort level: Lite
Fixes #46
Mudanças
ErrorResponse(String message)para respostas de erro padronizadas, sem expor detalhes internos.@ExceptionHandler(Exception.class)emControllerExceptionHandlerque captura qualquer exceção não mapeada, retornando500 INTERNAL_SERVER_ERRORcom mensagem genérica ("Erro interno no servidor").@Slf4j(log.error) para diagnóstico no servidor, seguindo o padrão de logm=<method>, campo=valorjá usado no projeto.InvalidFieldsException,MissingServletRequestParameterException) continuam funcionando sem regressão.Testes
./gradlew test— build e testes passando.