Validation과 Exception Handling

Validation과 Exception Handling

validate 및 예외 처리를 수행하는 전략에 대해 생각해본 내용을 정리했다. 

예외가 발생할 가능성이 낮다면, 불필요한 Validation은 피하는 것이 좋다.

• 평소에는 발생하지 않는 오류라면, 불필요한 validation은 코드의 가독성을 해칠 수 있고, 성능을 저하시킬 가능성이 있다. 
• 예를 들어, count가 2 또는 3 이외의 값이 들어올 일이 거의 없는데, 불필요한 default case를 추가하여 IllegalArgumentException을 던지는 것이 꼭 필요할까?
  • 만약 count 값이 비즈니스 로직 상 절대 변하지 않는 값이라면, 애초에 해당 값이 올바른 범위를 벗어나는 일이 없도록 설계하는 것이 더 낫다. 
  • 즉, 사전에 Enum, 상수, 제한된 데이터 구조를 활용하여 유효하지 않은 값이 들어오는 것을 차단하는 것이 더 좋은 접근법일 수 있다. 

 

enum TmType {
    TWO, THREE
}

public int getTmResult(TmType tmType, DyeTm dyeTm) {
    return switch (tmType) {
        case TWO -> (dyeTm.isLow() ? 0 : 1);
        case THREE -> (dyeTm.isLow() ? 0 : (dyeTm.isMid() ? 1 : 2));
    };
}

---

예외가 발생하더라도 시스템을 안정적으로 유지하는 것이 중요하다.

• 예외가 발생한다고 해서 무조건 throw 하는 것이 아니라, 프로그램의 안정성을 고려해야 한다. 
• 만약 예외가 발생했을 때 어떤 대체 값을 사용할지 또는 최소한의 서비스 영향만 주도록 할지 고민해야 한다.
  • 예외가 발생할 가능성이 낮은 경우, 무조건 예외를 던지기보다 기본값을 반환하거나 Fallback 로직을 추가하는 것이 더 안전할 수 있다. 

 

public int getTmResult(int count, DyeTm dyeTm) {
    return switch (count) {
        case 2 -> (dyeTm.isLow() ? 0 : 1);
        case 3 -> (dyeTm.isLow() ? 0 : (dyeTm.isMid() ? 1 : 2));
        default -> {
            System.out.println("WARN: Unexpected tmCount value: " + tmCount);
            yield -1; // 예외를 던지지 않고 기본값 반환
        }
    };
}

 

---

 Validation이 꼭 필요하다면, Exception을 던지기 전에 의미 있는 로그를 남기자. 

• 개발 중에는 IllegalArgumentException을 바로 던져도 괜찮지만,운영 환경에서는 원인을 파악할 수 있도록 로그를 남기는 것이 필수적이다. 
• 단순히 throw 하는 것보다, 로그와 함께 어떤 값이 문제인지, 왜 발생했는지 기록하는 것이 중요한 것 같다. 
  • 기본적인 부분이지만 SLF4J 같은 프레임워크를 활용하여, 예외 발생 시 문맥(Context)과 함께 상세한 로그를 기록하고, 그리고 예외 발생 시 서비스가 중단되지 않도록 적절한 대응 로직을 추가하는 것도 필수적일 것이다. 

---

결론

• 정말 절대 발생해서는 안 되는 상황 (그대로 지나가면 더 큰 에러가 발생하는 경우 등 ) 이라면, RuntimeException을 던지는 것이 맞다. 로그도 잊지 말자. (디버깅이 중요! )
• 하지만, 그 예외가 비즈니스 로직에서 자연스럽게 해결될 수 있다면 예외보다는 기본값 제공이 나은 것 같다.  

관련해서 에러를 어디서부터 방어하고 throw 할 지, 발생한 위치에서 얼마나 상위계층에서 exception을 처리할 지 등등에 대한 고민도 있었는데, 다음 글에 정리되어 있다. 

 

https://ebang.tistory.com/162 

애플리케이션 에러 로깅하기, 에러 핸들링 (feat. clean code)

 

더 중요한 건 에러 핸들링도 중요하지만, 에러가 없는 설계를 위해서 노력해보자! 화이팅!