[책리뷰/Effective Java] 예외

예외 처리에 대한 내 결론이올시다

Parameter Validation in Controller

• parameter validation 은 controller 내에서 진행

Service (Business)

• service 로직에서 발생한 예외에 대해서는 cause, stacktrace 가 필요함.
• 표준 예외를 적극적으로 사용 (정의된 메시지 사용)
• 특정 로직에 대한 예외처리가 필요한 경우 custom exception 사용
• custom exception handling 은 controller 에서 정의

catch (NoSuchMethodException e) {
   throw new MyServiceException("Some information: " + e.getMessage());  //Incorrect way
}
catch (NoSuchMethodException e) {
   throw new MyServiceException("Some information: " , e);  //Correct way
}

Method (API)

• checked exception 에 대해 throws 선언
• 빈 catch 블록을 생성하거나 예외를 무시하지 말 것

catch (NoSuchMethodException e) { //Incorrect way
   return null;
}

public void foo() throws Exception { //Incorrect way
}

public void foo() throws SpecificException1, SpecificException2 { //Correct way
}

ref)
standard exception vs custom exception
exception handling best practice
custom exception handling best practice

Ref [standard exception vs custom exception] 에 대한 소견

표준 예외를 적극적으로 사용하자!

• 예외 메시지로도 충분히 의미를 전달할 수 있다.
• 표준 예외를 사용하면 가독성이 높아진다.
• 일일히 예외 클래스를 만들다보면 지나치게 커스텀 예외가 많아질 수 있다.

사용자 정의 예외가 필요하다?

• 이름으로도 정보 전달이 가능하다. — 반론) message에서도 충분히 가능하다
• 상세한 예외 정보를 제공할 수 있다. — 반론) back 에서는 message로 충분히 커버가 가능하며, front에서 예외에 대한 상세 내용이 필요하다면 ErrorResponse에 대한 클래스가 정의를 한다
• 예외에 대한 응집도가 향상된다. — 전달하는 정보의 양이 많아질수록? 이건 오케이 — 책임소재? stacktrace 활용하면 되지 않나? — 같은 예외가 여러 곳에서 사용? standard exception 으로 충분히 커버 가능하지 않나?
• 예외 발생 후처리가 용이하다. — 발생위치 파악이 힘듬? stacktrace
• 예외 생성 비용을 절감 — stacktrace는 필요하다고 본다.