[아이템 70] 호출하는 쪽에서 복구하리라 여겨지는 상황이라면 검사 예외를 사용하라.

[epicblues]

page 390. 두 번째 문단

혹시 검사 예외를 활용해서 프로그램을 복구시키는 코드를 작성해 보신 경험이 있으신지 궁금합니다! 아니면 저희가 과정 초반부에 JdbcDriver를 활용할 때 작성한 예외 처리 코드가 그런 예시에 속하는 걸까요? 복구라는 개념이 잘 와닿지 않네요!😥

public int updateCustomerName(UUID customerId, String name) {
    try (
      var connection = DriverManager.getConnection("jdbc:mysql://localhost/order_mgmt", "root", "root1234!");
      var statement = connection.prepareStatement(UPDATE_BY_ID_SQL);
    ) {
      statement.setString(1, name);
      statement.setBytes(2, customerId.toString().getBytes());
      return statement.executeUpdate();
    } catch (SQLException throwable) {
      logger.error("Got error while closing connection", throwable); // 로깅만 하고 프로그램을 종료시키지는 않기 때문에 복구 코드?
    }
    return 0;
  }

[kimziou77]

JdbcDriver를 활용할 때 작성한 예외 처리 코드가 그런 예시에 속하는 걸까요?

넴 맞다고 생각합니다!

복구라는 개념이 잘 와닿지 않네요!😥

에러가 나면 정상적인 시스템 흐름에서 탈출해서 해당 에러를 복구 할 수 있는 상위로 throw 되다가 마지막 main에서도 처리가 되지 않으면 프로그램이 종료가 되는데, 이걸 상위 어딘가에서 탈출하려는 에러를 catch로 잡아가지고 정상 로직으로 다시 끌어다 오기 때문에 복구 라는 용어가 붙었다고 머리속에 어딘가 희미한 기억이 있네요...

---

물론 catch해서 로깅만 해도 시스템을 정상 로직으로 복구 시킬 순 있겠지만 오류난 코드에서부터 catch부분까지는 정상 실행되지 않은 상태입니다.

모든 로직이 처리되지 않고 중간에 끝났으니, 종료하지 않고 이어서 계속 사용할 것이라면 했었던 작업을 정리해주는 작업들이 필요할 것 같습니다 (ex - 롤백, 파일닫기 등...)

저의 생각 결론 부분 →→→ 복구코드는 맞는데 그렇게만(로깅만) 사용한다면 좋은 코드는 아니지 않을까??! 싶습니다!

[Leeyerimearth]

개인적인 의견이니 참고만 해주세용

저는 읽으면서 검사 예외가 비지니스 로직 측면에서 발생하는 예외와 가깝지 않을까....? 하는 생각을 했습니다. (온전히 비지니스로직에 의해 발생하는 예외를 뜻하는 건 아니고 상황복구 할 수 있다면 물론 시스템 예외도 포함이라고 생각합니다!)

예를들면 회원가입을 할 때, 동일한 이메일로 회원가입을 하려고하면 듀플이라고 예외를 발생시킬 수 있고 예외를 받는 쪽에서는 얜 이미 사용된 이메일이다 이렇게 복구처리를 할 수 있는데, 이런케이스를 말하는게 아닐까 생각했습니다. (실제로 사용자 중복 -> 예외 ! 라는것은 기획으로 만들어진 의도된 예외이지 시스템적인 측면에서의 예외는 아님)

수빈님 말씀해주신 것처럼 정상 로직 흐름을 이어나가게 할 수 있는 예외처리가 아닌가 싶습니다 !