realizers

메서드가 던지는 모든 예외를 문서화하라 메서드가 던지는 예외는 그 메서드를 올바로 사용하는데 아주 중요한 정보입니다. 따라서 각 메서드가 던지는 예외는 하나하나 문서화하는데 충분한 시간을 투자해야 합니다. 검사 예외(Checked Exception)은 항상 따로따로 선언하고, 각 예외가 발생하는 상황을 자바독의 @throws 어노테이션을 사용해 정확히 문서화해야 합니다. 💡 공통 상위 클래스 하나로 뭉뚱그려 선언하는 일은 삼가야 합니다. 극단적인 예로 Exception이나 RuntimeException, Throwable을 던진다고 선언해서는 안됩니다. 메서드 사용자에게 각 예외에 대처할 수 있는 힌트를 주지 못할뿐더러, 같은 맥락에서 발생할 여지가 있는 다른 예외들까지 삼켜버릴 수 있습니다. 💡 비검사..

표준 예외를 사용하라 숙련된 프로그래머는 미숙한 프로그래머보다 더 많은 코드를 재사용한다고 합니다. 예외도 마찬가지로 재사용하는 것이 좋으며, 자바 라이브러리는 대부분 API에서 쓰기에 충분한 수의 예외를 제공하고 있습니다. 💡표준 예외를 사용하면 얻는 이점 다른 개발자가 익히고 사용하기 쉬워집니다. 개발자 입장에서는 낯선 프로그램이라 할지라도 익숙한 표준 예외를 던져준다면 읽기 쉬울 것입니다. 예컨대 NotFoundMyChildrenException보다는 IllegalStateException이 조금 더 익숙할 것입니다. 예외 클래스 수가 적을수록 메모리 사용량도 줄고 클래스를 적재하는 시간도 적어집니다. 💡Exception, RuntimeException, Throwable, Error는 직접 재사용..

필요 없는 검사 예외 사용은 피하라 검사 예외(Checked Exception)를 싫어하는 프로그래머가 많지만 제대로 사용한다면 API와 프로그램의 질을 높을 수 있습니다. 개인적으로 싫어하는 유형은 필자처럼 try-catch 블럭으로 인해 혹여나 지저분해지지 않을까? 생각할 수도 있을거 같습니다. 하지만 검사 예외(Checked Exception)를 잘 사용한다면 발생한 문제를 프로그래머가 처리하여 안전성을 높일 수 있습니다. 💡예시 아래 예제 코드에서는 CheckedException을 발생시키는 메서드를 호출하여 main 메서드에서 try-catch하거나 혹은 throws를 사용하여 상위 호출자로 던져야 합니다. public static void main(String[] args) { ThrowChe..

복구할 수 있는 상황에는 검사예외를, 프로그래밍 오류에는 런타임 예외를 사용하라 💡 문제 상황을 알리는 방법 Checked Exception UnChecked Exception Error 💡 Checked Exception과 Unchecked Exception을 구분 하는 기본 규칙 호출하는 쪽에서 복구하리라 여겨지는 상황이라면 Checked Exception을 사용해야 합니다. Checked Exception을 던지면 호출자가 그 예외를 try-catch로 잡아 처리하거나 throws를 해야합니다. 아래 코드에서는 FileInputStream은 호출하는 쪽에서 예외가 발생하면 알아서 복구해~ 라고 말하고 있으니 try-catch로 감싸거나 throws를 해야합니다. public void checkedE..