Java Spring Boot微服务异常处理

Question

Java异常处理分为错误、已检查异常和未检查异常。这个问题是关于例外的。

正常的Java异常处理是扩展检查异常的异常类，并通过考虑异常层次结构来处理您需要的异常。

例如：

public class ExceptionA extends Exception {}

public class RunClass {

    public static void main() {
        try {
            RunClass runClass = new RunClass();
            runClass.doSomething();
        } catch(ExceptionA eA) {
            // Do ExceptionA related resolutions.
        } catch(Exception e) {
            // Do Exception related resolutions.
        }
    }

    public doSomething() throws ExceptionA {
        throw new ExceptionA();
    }
}

但是我看到了主要的Spring书籍，甚至在Spring boot中提到的Internet教程中，以及在微服务的上下文中，总是从RuntimeException类扩展而来，即使使用@ControllerAdvice。

这显然违反了Java异常处理的基本原则。但是仍然有一个论点说，它是用RuntimeException扩展的，因为这个异常是由@ExceptionHandler方法处理的，并且它是在运行时生成和处理的。

尽管如此，由于RuntimeExcure的这个扩展使得编译时异常处理跟踪不可见，并且很难追溯异常是如何抛出的。由于这些原因，我仍然相信，遵循基本的Java检查和未检查的异常处理概念仍然与@ExceptionHandler方法。

例如：

public class ExceptionRA extends RuntimeException {}

@ContollerAdvice
public class ExceptionHandler {

    @ExceptionHandler(ExceptionRA.class)
    public String handleException (Exception exception, Model model) {
        return "exception";
    }

}

@Controller
public class RunClass {

    @RequestMapping("/url1")
    public doSomething() {
        throw new ExceptionRA();
    }
}

我应该使用@ExcpetionHadler遵循所有异常场景的扩展RuntimeException，还是使用@ExceptionHaldler遵循基本的Java检查和取消检查机制？欢迎提出意见、建议和更正。

Answer 1

   @ControllerAdvice
    public class ExceptionController {

        @ExceptionHandler(NotFoundException.class)
        public ResponseEntity<List<ErrorDto>> handleNotFoundException(NotFoundException e){
            final String message = "The provided id is not in DB" + e.getMessage() + " " + "not found";
            final List<ErrorDto> errorDto = new ArrayList<>();
            errorDto.add(new ErrorDto("400", message, e.getField()));
            return new ResponseEntity<>(errorDto, HttpStatus.BAD_REQUEST);

        }

====================================================================================

@Data
public class ErrorDto {
    private String code;
    private String message;
    private String field;

}

====================================================================================

以下链接供参考：（逐步解释）

https://www.youtube.com/watch?v=OLt_CiNsu4A

Answer 2

选中/未选中异常的首选项就像宗教一样。

您通常不会在自己的代码中调用控制器方法。通常，您不会有如下代码：

try {
   runClass.doSomething();
} catch(ExceptionRA exra) {
  // Handle handle handle
}

因此，您不会直接从控制器方法抛出的已检查异常中获益。他们不会强制任何检查过的处理，因为没有地方处理它们。所以您也可以抛出未检查的异常，并缩短方法签名。从控制器方法中抛出已检查的异常没有任何附加值。

控制器正在调用的某些Busines服务方法也可能引发异常。这就引出了两个问题：

• 您应该在业务逻辑中使用已检查或未检查的异常吗
• 如果业务逻辑抛出选中的异常，是否应该将其包装为未选中的异常？还是只是路过

第一个问题的答案是——你不应该让这个决定受到你在控制器中所做的事情的影响。按照你的“例外宗教”去做。若您更喜欢选中的异常，那个么使用选中的异常，无论您是否在控制器中使用未选中的异常。

第二个问题是否定的。假设您的业务逻辑抛出检查异常。如果此异常将充分代表调用方的情况，则没有理由将其包装为任何其他异常，无论是选中还是未选中。如果您的业务异常没有向调用方正确解释情况，最好将其包装起来。然后，未经检查的异常将使您的签名更短。

现在是个人意见。除了编程错误之外，我通常更喜欢检查异常。我也在控制器中使用它们（更不用说有点长的方法签名）。