아이템 77. 예외를 무시하지 말라 메서드를 사용할 때, 메서드 시그니쳐에 선언된 예외는 절대로 무시하면 안됨. (반드시 처리해야한다는 것을 의도한 것임) 만약 무시해도 괜찮은 예외라면, 예외 이름을 Ignore로 바꾸고 이유를 Catch 절에 주석으로 작성해야 함. 메서드 시그니쳐의 예외 → 무시하지 마. API 설계자가 메서드를 설계할 때, 시그니쳐에 예외를 명시하는 이유는 이 API를 사용하는 사람들이 그 예외에 대한 조치를 취해달라고 요청하는 것이다. 따라서 예외가 시그니쳐에 명시된 메서드를 사용할 때는 반드시 예외에 대한 적절한 조치를 해야한다. // Catch 블록을 비워두면 예외가 무시된다. try { ... } catch (SomeException e) { } catch로 예외를 잡은 후,..
아이템 69. 예외는 진짜 예외 상황에만 사용하라. 예외는 진짜 예외 상황에서만 사용해야함. 예외를 잘못 사용한 예시 흐름제어에 예외를 사용함 → 흐름제어에 사용된 예외 때문에 진짜 예외가 무시되어 디버깅이 어려워 질 수 있음. 예외 대신 흐름제어에 사용할만한 것 Optional 상태 검사 메서드 특정 값 중 하나 선택 선택 기준 Optional이나 특정값 사용 상태 검사 메서드 - 상태 메서드 사이에 동시성 문제가 있을 수 있는 경우 성능이 중요한데, 상태 검사 메서드 / 상태 메서드가 중복된 작업이 일부 있는 경우 나머지 경우 상태 검사 메서드 사용하는 것이 유리. 예외를 잘못 사용한 경우. 아래 코드는 무엇을 의미하는 것일까? 단순히 코드만 봤을 때는 무엇을 하는지 전혀 알 수 없다. // 아래 코..
Method 10 100 1000 1,000,000 10,000,000 100,000,000 simpleFunctionWithoutLock 1ms 1ms 2ms 37ms 1.6s 20.9s simpleFunctionWithLock 0ms 0ms 1ms 20ms 0.7s 21.3s simpleFunctionWithLockSleep 106ms 1040ms 109700ms - - - Method 10 100 1,000 10,000 100,000 1,000,000 10,000,000 100,000,000 putWithoutLock 1ms 1ms 3ms 9ms 34ms 217ms 2085ms 23558ms putWithLock 1ms 1ms 2ms 7ms 28ms 172ms 920ms 20060ms Method ..
아이템 70. 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라. 체크 예외 : 복구할 수 있는 상황일 때 던져라. 언체크 예외 : 복구할 수 없는 상황일 때 던져라. 언체크 예외를 구현할 때는 반드시 RuntimeException 클래스를 상속해서 만들어라. 복구 가능한 상황인지 잘 모르겠으면, 언체크 예외를 던져라 필요하다면 예외 클래스에 도우미 메서드를 추가해서 복구를 손쉽게 할 수 있도록 하는게 좋을 수 있음. 몇 초 후에 재시도 해야한다는 메세지가 있다면, 그 메세지를 예외에 넣는다. 그리고 사용자에서 이 값을 간단히 get() 메서드를 이용해서 사용해 볼 수도 있다. 체크 예외 vs 언체크 예외 자바에서는 크게 두 가지 타입의 예외가 존재한다. 체크 예외 : 예..
아이템 71. 필요없는 체크 예외 사용은 피하라 체크 예외는 복구 가능한 상황을 알려서 이 API를 사용하는 개발자가 복구를 시도하도록 강제함. 복구 불가능한 예외라면 비검사 예외를 던져서 사용하기 편리한 API를 제공 해야 함. 복구 가능한지 명확하지 않다면 비검사 예외를 던져라. 검사 예외가 추가되면 다음 문제가 발생함. try ~ catch를 사용해야 함. Stream에서 사용할 수 없음. 검사 예외를 회피하는 방법 Optional 반환하기 → 단점은 예외 정보가 없음. 검사 예외를 던지는 메서드를 2개로 쪼개서, 상태 검사로 분기 처리하기 → 멀티 쓰레드 환경에서 상태검사 동기화가 필요함. 체크 예외를 던지면 사용하기 어려운 API가 됨. 메서드에서 체크 예외를 던지면, 이 메서드를 사용하는 클라..