Является ли хорошей практикой иметь обработчик класса Generic Exception в глобальном обработчике исключений с пружинным отдыхом?

Question

Я ссылался на несколько статей, чтобы создать глобальный обработчик исключений, используя @ControllerAdvice для моего проекта api rest, использующего spring.Цель этого состоит в том, чтобы отправить правильно отформатированный ответ клиенту в случае возникновения исключения.В некоторых статьях они добавили Throwable или Exception в глобальный обработчик исключений.Должен ли я заменить его на RunTimeException, так как этот блок для исключения произошел во время выполнения?

Код обработчика исключений:

@ControllerAdvice
public class GlobalExceptionHandler{

    @ExceptionHandler(NoDataFoundException.class)
    @ResponseStatus(code=HttpStatus.NOT_FOUND)
    public ResponseEntity<ErrorResponse> handle(NoDataFoundException ex){
        ErrorResponse errorResponse = new ErrorResponse(ex.getMessage(), HttpStatus.NOT_FOUND.value());
        ResponseEntity<ErrorResponse> response = new ResponseEntity<ErrorResponse>(errorResponse, HttpStatus.NOT_FOUND);
        return response;
    }
    ..... more methods to handle custom exceptions

    @ExceptionHandler(Exception.class)
    @ResponseStatus(code=HttpStatus.INTERNAL_SERVER_ERROR)
    public ResponseEntity<ErrorResponse> handle(Exception ex){
        ErrorResponse errorResponse = new ErrorResponse("Something went wrong", HttpStatus.INTERNAL_SERVER_ERROR.value());
        ResponseEntity<ErrorResponse> response = new ResponseEntity<ErrorResponse>(errorResponse, HttpStatus.INTERNAL_SERVER_ERROR);
        return response;
    }
}

Код ErrorResponse:

public class ErrorResponse {

    private String message;
    private int statusCode;

    public ErrorResponse(String message, int statusCode) {
        super();
        this.message = message;
        this.statusCode = statusCode;
    }
    public String getMessage() {
        return message;
    }
    public void setMessage(String message) {
        this.message = message;
    }
    public int getStatusCode() {
        return statusCode;
    }
    public void setStatusCode(int statusCode) {
        this.statusCode = statusCode;
    }
}  

Ссылки:

1. https://dzone.com/articles/exception-handling-in-spring-boot-rest-web-service
2. https://github.com/in28minutes/spring-boot-examples/tree/master/spring-boot-2-rest-service-exception-handling

Answer 1

Честно говоря, иметь дескриптор обработчика исключений Exception кажется мне немного ленивым.Так как Exception проверен, вы должны нести ответственность за обработку или восстановление после ошибки.Если вы не не в состоянии восстановиться после ошибки, или обстоятельства, в которых вы находитесь, мешают вам написать код, который позволяет элегантно восстанавливаться, его следует перебросить в RuntimeException вместоуказать на проблему.

Конечно, обработчики исключений служат двум целям:

• Они дают вам возможность определить стандарт того, как выглядят ответы об ошибках и что они содержат в деталях.
• Они дают вам возможность регистрировать ошибку, чтобы вы могли вернуться позже и исправить ее.

Я бы настоятельно рекомендовал использовать схему повторных бросков, помеченную Exception s какне проверяется и обрабатывает тех, кто в обработчиках исключений.В качестве отказоустойчивой ловушки вы можете использовать универсальный обработчик исключений для Exception, чтобы перехватить все точки, которые не были преобразованы, и записать, что произошло.

Это должно Никогда не означает, что вы, как разработчик, разрешаете Exception распространяться до самого верха без явной причины.

Answer 2

Должен ли я заменить его на RunTimeException, так как этот блок предназначен для исключения, произошедшего во время выполнения?

Чтобы убедиться, что вы перехватываете любое исключение, которое никогда не обрабатывается вашими компонентами или обработчиком исключенийс более типизированным исключением, чем Exception, у вас должен быть обработчик для Exception.
. Обработчика для RuntimeException недостаточно, поскольку проверенное исключение также генерируется во время выполнения и если объявления методов компонентов высокого уровняукажите throws Exception или throws "any checked exception", проверенное исключение может распространяться до тех пор, пока клиент или контейнер не будут применять поведение по умолчанию.
Например, представьте объявление этого метода rest rest controller, которое может привести к возникновению такой ситуации:

@RequestMapping(value = "/{id}", method = RequestMethod.GET)
public ResponseEntity<Foo> getOne(@PathVariable long id) throws Exception {
       // ....           
}

И чтобы переопределить это поведение Spring по умолчанию, вы захотите добавить обработчик для Exception.
Конечно, это не означает, что объявление обработчика только для Exception является способомно у вас может быть какое-то исключение без особой обработки и для этого общего хаНиндлинг в порядке.