Develog

🎯 아이템 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..

🎯 아이템 69. 예외는 진짜 예외 상황에만 사용하라. 예외를 완전히 잘못 사용한 예 - 따라 하지 말 것! try{ int i = 0; while(true) range[i++].climb(); } catch (ArrayIndexOutOfBoundsException e){ } 위 코드는 무한루프를 돌다가 배열의 끝에 도달해 ArrayIndexOutOfBoundsException이 발생하면 끝을 내는 것이다. 하지만 표준적인 관용구인 for-each로 작성했다면 더 이해하기 쉽다. for(Mountaion m : range) m.climb(); 그런데 예외를 써서 루프를 종료한 이유는 뭘까? 그 이유는 잘못된 추론을 근거로 성능을 높여보려 한 것이다. JVM은 배열에 접근할 때마다 경계를 넘지 않는지 검사..

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