코딩 잘하고 싶어

메서드가 저수준 예외를 처리하지 않고 바깥으로 전파했을 때 수행하려는 일과 관련 없어 보이는 예외가 발생 내부 구현 방식을 드러내어 윗 레벨 API를 오염 구현 방식을 바꾸면 다른 예외가 발생하여 기존 클라이언트 프로그램을 깨지게함 예외 번역 (exception translation) 위 문제를 피하기 위해선 상위 계층에서 저수준 예외를 잡아 자신의 추상화 수준에 맞는 예외로 바꿔 던져야함 (예외 번역) try { // 저수준 추상화를 이용 } catch (LowerLevelException e) { // 추상화 수준에 맞게 번역 throw new HigherLevelException("exception"); } // AbstractSequentialList에서 수행하는 예외번역 예시 public abs..

표준 예외 자바 라이브러리는 대부분 API 에서 쓰기 충분한 수의 예외를 제공하므로 이를 재사용하자. 표준 예외를 재사용하면 장점이 많음 다른 사람이 익히고 사용하기 쉬움 예외 클래스 수가 적을수록 메모리 사용량과 클래스를 적재하는 시간을 아낄 수 있음 자주 사용되는 표준 예외 예외 주요 쓰임 IllegalArgumentException 허용하지 않는 값이 인수로 건네졌을 때 (null은 NullPointerException으로 처리) IllegalStateException 객체가 메서드를 수행하기에 적절하지 않은 상태 NullPointerException null을 허용하지 않는 메서드에 null을 건넸을 때 IndexOutOfBoundsException 인덱스가 범위를 벗어났을 때 Concurrent..

검사 예외를 제대로 활용하면 검사 예외를 제대로 활용하면 API와 프로그램의 질을 높임 (검사 예외는 처리하여 안전성을 높일 수 있기 때문) 검사 예외를 과하게 사용하면 검사 예외는 호출자가 처리해야하는 강제성을 지니기 때문에 부담을 주게 된다. 검사 예외를 던지는 메서드는 스트림 안에서 직접 사용할 수 없어서 [아이템 45~48] 부담을 주게 된다. 특히, 메서드가 단 하나의 검사 예외만 던질 때 부담이 큼 그 예외 하나 때문에 API 사용자는 try블록을 추가하고 스트림에서 사용하지 못하게 됨 이런 상황에선 검사예외를 안 던질 방법이 없는지 고민해보자 검사 예외 회피 방법 1) Optional [아이템 55] 적절한 결과 타입을 담은 옵셔널은 반환하는 것이 검사 예외를 회피하는 가장 쉬운 방법 검사 ..

Throwable 자바는 문제 상황을 알리는 타입(throwable)으로 검사 예외, 런타임 예외, 에러 이렇게 3가지를 제공 검사 예외 (Checked Exception) 호출하는 쪽에서 복구하리라 여겨지는 상황이면 검사 예외를 사용 검사 예외를 던지면 호출자가 그 예외를 catch로 처리하거나 더 바깥으로 던지도록 강제하게 된다. API 설계자는 API 사용자에게 검사 예외를 던져주어 그 상황에서 회복하라고 요구한 것 검사 예외는 Exception의 하위 클래스 중 RunitmeException을 상속하지 않는 것 호출자가 예외 상황에서 벗어나는 데 필요한 정보를 알려주는 메서드를 함께 제공하자. 비검사 예외 (Unchecked Exception) 프로그램에서 복구가 불가능하거나 더 실행해봐야 득보다..

// 예외를 완전 잘못 사용한 예 try { int i = 0; while (true) { range[i++].climb(); } } catch (ArrayIndexOutOfBoundsException e) { } 위 코드는 직관적이지 않게 예외를 작성하였다. 무한루프를 돌다가 배열의 끝에 도달해 예외가 발생하면 끝을 내는 것이다. 이 코드를 아래와 같이 작성 했다면 모든 프로그래머가 이해할 수 있을 것이다. for(Mountain m : range) m.climb(); 그런데 예외를 쓴 이유가 무엇일까? 3가지 면에서 잘못된 추론을 해서 예외를 사용한게 더 성능이 좋을 것이라고 생각했을 가능성이 있다. 이를 바로잡고자 한다. 1) 예외는 예외상황에 쓸 용도로 설계되어서 JVM 구현자 입장에서는 명확한 ..

철자 규칙 패키지, 클래스, 인터페이스, 메서드, 필드, 타입 변수의 이름을 다룸 특별한 이유가 없는 한 따라야함 → 어기면 코드를 읽기 어렵고 유지보수하기 어려움 1) 패키지와 모듈 각 요소를 점(.)으로 구분하여 계층적으로 짓기 요소들은 모두 소문자 알파벳 혹은 드물게 숫자로 이루어짐 조직의 인터넷 도메인 이름을 역순으로 사용 ex) com.google, org.eff 예외로 표준 라이브러리는 java, 선택 패키지들은 javax로 시작 패키지 이름의 나머지는 해당 패키지를 설명하는 하나 이상의 요소로 이루어짐 각 요소는 8자 이하의 짧은 단어로 (한 단어 혹은 약어) 2) 클래스와 인터페이스 하나 이상의 단어로 이루어짐, 각 단어는 대문자로 시작 ex) List 여러 단어의 첫글자만 딴 약자나 ma..

최적화는 오히려 좋은 결과보다 해로운 결과로 이어지기 쉽다. 빠르지도 않고 제대로 동작하지도 않고 수정하긴 어려운 소프트웨어가 탄생할 수 있다. 빠른 프로그램보다는 좋은 프로그램을 작성하라 성능 때문에 견고한 구조를 희생하지 말자. (견고한 구조 - 내부 응집성이 높고 외부와 결합성이 낮은) 좋은 프로그램은 정보 은닉 원칙을 따라 개별 컴포넌트의 내부가 독립적으로 설계됨 → 나머지에 영향 주지않고도 각 요소를 재설계 가능 [아이템 15] 완성된 아키텍처의 결함이 성능을 제한하는 상황이라면 시스템 전체를 작성해야 해결 할 수 있기 때문에 설계 단계에서 성능을 반드시 염두에 두자. 성능을 제한하는 설계를 피하라 완성 후 변경하기 가장 어려운 설계 요소는 컴포넌트끼리, 또는 외부 시스템과의 소통 방식 ex) ..

자바 네이티브 인터페이스 (Java Native Interface, JNI) 자바 프로그램이 네이티브 메서드를 호출하는 기술 네이티브 메서드 : C나 C++ 같은 네이티브 프로그래밍 언어로 작성한 메서드 네이티브 메서드의 주요 쓰임 1) 레지스트리 같은 플랫폼 특화 기능 사용 자바가 성숙해가면서 (OS같은) 하부 플랫폼 기능을 흡수하고 있음 → 점차 네이티브 메서드 사용 필요성 감소 ex) 자바9는 processAPI를 추가하여 OS 프로세스에 접근할 수 있도록 함 2) 네이티브 코드로 작성된 기존 라이브러리 사용 레거시 데이터를 사용하는 레거시 라이브러리 대체할만한 자바 라이브러리가 없는 네이티브 라이브러리를 사용해야할때 네이티브 메서드 써야함 3) 성능 개선을 목적으로 성능에 결정적인 영향을 주는 영..