Develog

🎯 아이템 74. 메서드가 던지는 모든 예외를 문서화하라. 메서드가 던지는 예외는 그 메서드를 올바로 사용하는 데 아주 중요한 정보다. 따라서 각 메서드가 던지는 예외 하나하나를 문서화하는 데 충분한 시간을 쏟아야 한다. 검사 예외는 항상 따로따로 선언하고, 각 예외가 발생하는 상황을 자바독의 @throws 태그를 사용하여 정확히 문서화하자. /** * ... 생략 * * @throws SecurityException if a security manager exists and its * checkPermission method denies enabling * subclassing. * @throws IOException if an I/O error occurs while creating this stre..

🎯 아이템 73. 추상화 수준에 맞는 예외를 던지라. 수행하려는 일과 관련 없어 보이는 예외가 튀어나오면 당황스러울 것이다. 메서드가 저수준 예외를 처리하지 않고 바깥으로 전파해버릴 때 종종 일어나는 일이다. 사실 이는 단순히 프로그래머를 당황시키는 데 그치지 않고, 내부 구현 방식을 드러내어 윗 레벨 API를 오염시킨다. 다음 릴리스에서 구현 방식을 바꾸면 다른 예외가 튀어나와 기존 클라이언트 프로그램을 깨지게 할 수도 있는 것이다. 이 문제를 피하려면 상위 계층에서는 저수준 예외를 잡아 자신의 추상화 수준에 맞는 예외로 바꿔 던져야 한다. 이를 예외 번역(exception translation)이라 한다. 참고 자료 Joshua Bloch, 『Effective Java 3/E』, 개앞맵시 옮김, 프로..

숙련된 프로그래머는 그렇지 못한 프로그래머보다 더 많은 코드를 재사용한다. 예외도 마찬가지로 재사용하는 것이 좋으며, 자바 라이브러리는 대부분 API에서 쓰기에 충분한 수의 예외를 제공한다. 하지만 어떤 예외를 사용해야할지 모른다고하여 Exception, RuntimeException, Throwable, Error는 직접 재사용하지는 말자. 예외 주요 쓰임 IllegalArgumentException 허용하지 않는 값이 인수로 건네졌을 때 IllegalStateException 객체가 메서드를 수행하기에 적절하지 않은 상태일 때 NullPointerException null을 허용하지 않는 메서드에 null을 건넸을 때 IndexOutOfBoundsException 인덱스가 범위를 넘어섰을 때 Conc..

🎯 아이템 71. 필요 없는 검사 예외 사용은 피하라. 결과를 코드로 반환하거나 비검사 예외를 던지는것과 달리, 검사 예외는 발생한 문제를 프로그래머가 처리하여 안전성을 높이게끔 해준다. 물론, 검사 예외를 과하게 사용하면 오히려 쓰기 불편한 API가 된다. 어떤 메서드가 검사 예외를 던질 수 있다고 선언됐다면, 이를 호출하는 코드에서는 catch 블록을 두어 그 예외를 붙잡아 처리하거나 더 바깥으로 던져 문제를 전파해야만 한다. 어느 쪽이든 API 사용자에게 부담을 준다. 더구나 검사 예외를 던지는 메서드는 스트림 안에서 직접 사용할 수 없기 때문에 자바 8부터는 부담이 더욱 커졌다. public class Main { public static void main(String[] args) { try {..

🎯 아이템 70. 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타입 예외를 사용하라. 호출하는 쪽에서 복구하리라 여겨지는 상황이라면 검사 예외를 사용하라. /** * 메뉴 등록 * @param menuVO * @throws Exception */ public void insertMenu(MenuVO menuVO) throws SQLException{ menuVO.setMenuSn(menuSnIdService.getNextStringId()); int dept = 1; if(CommonConstants.INNO_ROOT_SN.getValue().equals(menuVO.getSupiMenuSn())){ menuVO.setDept(dept); } else { menuVO.setDept(men..

🎯 아이템 66. 네이티브 메서드는 신중히 사용하라. 네이티브 메서드를 사용하려거든 한번 더 생각하라. 네이티브 메서드가 성능을 개선해주는 일은 많지 않다. 저수준 자원이나 네이티브 라이브러리를 사용해야만 해서 어쩔 수 없더라도 네이티브 코드는 최소한만 사용하고 철저히 테스트하라. 네이티브 코드 안에 숨은 단 하나의 버그가 여러분 애플리케이션 전체를 훼손할 수도 있다. 🎯 아이템 67. 최적화는 신중히 하라. 빠른 프로그램을 작성하려 안달하지 말자. 좋은 프로그램을 작성하다 보면 성능은 따라오게 마련이다. 1️⃣ 성능을 제한하는 설계를 피하라. 완성 후 변경하기가 가장 어려운 설계 요소는 바로 컴포넌트끼리, 혹은 외부 시스템과의 소통 방식이다. 이런 설계 요소들은 완성 후에는 변경하기 어렵거나 불가능할 ..