Reference/Effective-Java

[Effective-Java] Chapter10 #74. 메서드가 던지는 모든 예외를 문서화하라

1️⃣ 검사 예외는 항상 따로따로 선언하고, 각 예외가 발생하는 상황을 @throws 태그로 정확히 문서화하라 공통 상위 클래스(Exception, Throwable)로 뭉뚱그려 선언하는 일은 삼가하라 메서드 사용자에게 대처할 힌트를 주지 못한다. 같은 맥락에서 발생할 여지가 있는 다른 예외까지 삼켜버릴 수 있다. main 메서드는 오직 JVM만이 호출하므로 Exception을 던져도 괜찮은 유일한 예다. 비검사 예외도 검사 예외처럼 문서화 해두면 좋다. 자신이 일으킬 수 있는 오류들을 알림으로써 프로그래머가 해당 오류가 나지 않도록 코딩하게 돕는다. 사실상 해당 메서드를 성공적으로 수행하기 위한 전제조건이 된다. 인터페이스 메서드의 경우 해당 조건이 일반 규약에 속하게 되어, 모든 구현체가 일관되게 동..

[Effective-Java] Chapter10 #73. 추상화 수준에 맞는 예외를 던져라

📌 예외 번역(Exception Translation) 💡 상위 계층에서는 저수준 예외를 잡아 자신의 추상화 수준에 맞는 예외로 바꿔 던져야 한다. try { ... // 저수준 추상화를 이용한다. } catch (LowerLevelException e) { throw new HigherLevelException(...); // 추상화 수준에 맞게 번역한다. } 메서드가 저수준 예외를 처리하지 않고 바깥으로 전파하면, 내부 구현 방식을 드러내 윗 레벨 API를 오염시킨다. 다음 릴리즈에서 구현 방식을 바꾸면 다른 예외가 튀어나와서 기존 Client 프로그램을 깨지게 할 수도 있다. 🟡 AbstractSequentialList AbstractSequentialList는 List의 골격 구현(Item 20)..

[Effective-Java] Chapter10 #72. 표준 예외를 사용하라

📌 장점 Java 라이브러리는 대부분 API에서 쓰기 충분한 수의 예외를 제공하니 재활용하라 우리가 작성한 API가 다른 사람이 익히고 사용하기 쉬워진다. 우리의 API를 사용하는 프로그램도 낯선 예외를 사용하지 않게 되어 읽기 쉬워진다. 예외 클래스 수가 적을 수록 memory 사용량이 줄고 클래스를 적재하는 시간이 감소한다. 📌 종류 예외 주요 쓰임 IllegalArgumentException 허용하지 않는 값이 인수로 건네졌을 때(null은 따로 NullPointerException으로 처리) IllegalStateException 객체가 메서드를 수행하기에 적절하지 않은 상태일 때 NullPointerException null을 허용하지 않는 메서드에 null을 건넸을 때 IndexOutOfBou..

[Effective-Java] Chapter10 #71. 필요 없는 검사 예외 사용은 피하라

📌 검사 예외의 장단점 🟡 pros 발생한 문제를 프로그래머가 처리하도록 강제하므로 안정성을 높인다. 구체적인 예외 타입과 그 타입이 제공하는 메서드들을 활용해 부가 정보를 제공할 수 있다. 🟡 cons 과하게 사용하면 쓰기 불편한 API가 된다. 호출자가 반드시 catch 블록을 두어 예외를 붙잡아 처리하거나, 바깥으로 던져야 하므로 사용자에게 부담을 준다. 검사 예외를 던지는 메서드는 스트림 안에서 직접 사용이 불가능하다. 단 하나의 검사 예외만 던질 때 가장 큰 부담을 준다. 다른 검사 예외도 던지는 상황이면 catch문 하나 추가하는 정도 검사 예외가 하나뿐이라면, 오직 그 예외 때문에 사용자는 try 블록을 추가하고 Stream을 사용할 수 없게 된다. 📌 검사 예외를 사용하는 경우 } catc..