<T>Story <T>Story

ITEM 77 예외를 무시하지 말라 예외를 무시하지 말라는 말은 당연한 이야기지만 사람들이 자주 어기고 있는 내용이다 API 설계자가 메서드 선언에 예외를 명시하는 이유는 그 메서드를 사용할 때 적절한 조치를 취해달라는 이야기다 API 설계자가 친절하게 써놓은 내용을 대충 듣지 말자 실제로 예외를 무시하는 일은 매우 쉽게 이루어 진다 // catch 블록을 비워버리면 예외가 무시된다 try { ... } catch (SomeException e){ } 예외는 문제 발생시 대처하는데 아주 중요한 요소인데 catch 블록을 비워두면 예외가 존재할 이유가 없다 비유하자면 화재 경보를 무시하는걸 넘어서 아예 꺼버려 다른 사람들도 화재 상황을 알지 못하게 하는 수준이다 빈 catch 블록을 목격한다면 항상 사이렌..

ITEM 76 가능한 한 실패 원자적으로 만들라 실패 원자적(failure-atomic) 호출된 메서드가 실패하더라도 해당 객체는 메서드 호출 전 상태를 유지해야 한다 메서드를 실패 원자적으로 만드는 방법 가장 간단한 방법은 불변 객체로 설계하는 것 불변 객체의 상태는 생성 시점에 고정되어 절대 변하지 않기 때문에 태생부터 실패 원자적이다 가변 객체를 실패 원자적으로 만드는 방법은 작업 수행에 앞서 매개변수 유효성을 검사하는 것이다 객체의 내부 상태를 변경하기 전에 잠재적 예외의 가능성 대부분을 걸러낼 수 있다 객체의 임시 복사본에서 작업을 수행하고 작업이 성공적으로 완료되면 원래 객체와 교체하는 것 데이터를 임시 자료구조에 저장해 작업하는게 더 빠를 때 적용하기 좋다 작업 도중 발생하는 실패를 가로채는..

ITEM 75 예외의 상세 메시지에 실패 관련 정보를 담으라 예외를 잡지 못해 프로그램이 실패하면 자바 시스템은 그 예외의 스택 추적(stack trace) 정보를 자동으로 출력한다 스택 추적은 예외 객체의 toString 메서드를 호출해 얻는 문자열이다 보통 예외의 클래스 이름 뒤에 상세 메세지가 붙는 구조다 이런 정보가 실패 원인을 분석해야 하는 개발자나 SRE가 얻을 수 있는 유일한 정보인 경우가 많다 더구나 실패를 재현하기 어렵다면 더 자세한 정보를 얻기가 어렵거나 불가능하다 따라서 예외의 toString 메서드에 실패 원인에 관한 정보를 가능한 많이 담아서 반환 하는게 중요하다 사후분석을 위해 실패 순간의 상황을 정확히 포착해 예외의 상세 메세지에 담아야 한다 실패 순간을 포착하려면 발생한 예외..

ITEM 74 메서드가 던지는 모든 예외를 문서화하라 메서드가 던지는 예외는 그 메서드를 올바로 사용하는데 아주 중요한 정보니 예외 하나하나 모두 문서화 하는게 좋다 검사 예외는 항상 따로따로 선언하고, 각 예외가 발생하는 상황을 자바독의 @throws 태그를 사용하여 정확히 문서화 하자 공통 상위 클래스 하나로 뭉뚱그려 선언 하지 말자 극단적인 예) 메서드가 Exception, Throwable을 던진다고 선언하면 안된다 메서드 사용자에게 각 예외에 대처할 수 있는 힌트를 주지 못한다 같은 맥락에서 발생 가능한 다른 예외까지 삼켜 API 사용성을 떨어뜨린다 이 규칙의 유일한 예외는 오직 JVM만이 호출하는 main 메서드이다 자바 언어가 요구하지는 않지만 비검사 예외도 검사 예외처럼 문서화 해두면 좋다..

ITEM 73 추상화 수준에 맞는 예외를 던져라 상위 계층에서는 저수준 예외를 잡아 자신의 추상화 수준에 맞는 예외로 바꿔 던져야 한다 그렇지 않으면 수행하려는 일과 관련 없어 보이는 예외가 발생해 내부 구현 방식을 드러내고 윗 레벨 API를 오염시키게 된다 다음 릴리스에서 구현 방식을 바꾸면 다른 예외가 나타나 기존 클라이언트를 깨지게 할 수도 있다 예외 번역 try { ... // 저수준 추상화를 이용한다 } catch (LowerLevelException e) { // 추상화 수준에 맞게 번역한다 throw new HigherLevelException(...); } 다음은 AbstractSequentialList에서 수행하는 예외 번역의 예다 AbstractSequentialList는 List 인터..

ITEM 72 표준 예외를 사용하라 표준 예외를 재사용하면 얻는게 많다 최고의 장점은 내가 만든 API가 다른 사람이 익히고 사용하기가 쉬워진다 많은 개발자들에게 이미 익숙해져 있는 규약을 따르기 때문 내가 만든 API를 사용한 프로그램도 낯선 예외를 사용하지 않게 되어 읽기 쉽게 된다 예외 클래스 수가 적을수록 메모리 사용량도 줄고 클래스를 적재하는 시간도 적게 걸린다 가장 흔하게 재사용 많이 되는 예외 IllegalArgumentException 허용하지 않는 값이 인수로 건네졌을때 (null 은 따로 NPE 처리) IllegalStateException 객체가 메서드를 수행하기에 적절하지 않은 상태인 경우 NullPointerException null을 허용하지 않는 메서드에 null을 건낸경우 I..

ITEM 71 필요 없는 검사 예외 사용은 피하라 검사 예외를 싫어하는 개발자가 많지만 제대로 활용하면 API와 프로그램의 질을 높일 수 있다 결과를 코드로 반환하거나 비검사 예외를 던지는 것과 다르게 검사 예외는 발생한 문제를 개발자가 처리해 안정성을 높여준다 하지만 검사 예외를 과하게 쓰면 오히려 쓰기 불편한 API가 된다 어떤 메서드가 검사 예외를 던질 수 있다면 이 메서드를 호출하는 코드에서는 catch 블록을 이용해 그 예외를 붙잡아 처리하거나 더 바깥으로 던져 문제를 전파해야된다 어느쪽이든 API 사용자에게 부담을 주며 검사 예외를 던지는 메서드는 스트림 안에서 직접 사용할 수 없기 때문에 자바8부터는 더욱 부담이 커졌다 API를 제대로 사용해도 발생할 수 있는 예외거나 개발자가 의미있는 조치..

ITEM 70 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라 자바에서 문제 상황을 알리는 타입(throwable) 세 가지 검사 예외 런타임 예외 에러 위 3가지의 사용 시점을 헷갈리는 개발자가 많으니 그에 관련한 지침을 알아보자 호출하는 쪽에서 복구하리라 여겨지는 상황이라면 검사 예외를 사용하라 검사와 비검사 예외를 구분하는 기본 규칙이다 검사 예외를 던지면 호출자가 그 예외를 catch로 잡아 처리하거나 더 바깥으로 전파하도록 강제하게 된다 따라서 메서드 선언에 포함된 검사 예외 각각은 그 메서드를 호출했을 때 발생할 수 있는 유력한 결과임을 API 사용자에게 알려주는 것이다 비검사 throwable은 런타임 예외와 에러 두가지다 둘다 동작 측면에서는 다르지 않으며..

ITEM 69 예외는 진짜 예외 상황에만 사용하라 운이 없다면 아래와 같은 코드를 마주칠 수도 있다 예외를 완전히 잘못 사용한 예 try { int i=0; while(true) range[i++].climb(); } catch (ArrayIndexOutOfBoundsException e) { } 무슨 일을 하는지 알 수 없는 직관적이지 않은 코드이며 배열의 원소를 아주 끔직한 방법으로 순회하고 있다 무한루프를 돌다가 배열의 끝에 도달해서 Exception이 발생하면 끝을 내는 방식이다 위 코드를 아래처럼 표준적인 관용구로 작성하면 다른 개발자가 바로 이해할 것이다 for (Mountain m : range) m.climb(); 그렇다면 왜 예외를 써서 반복문을 빠져나오게 했을까? 잘못된 추론을 근거로 ..

ITEM 68 일반적으로 통용되는 명명 규칙을 따르라 자바 플랫폼은 명명 규칙이 잘 정립되어 있고 그중 많은 것이 자바 언어 명세에 기술되어 있다 자바의 명명 규칙은 크게 철자와 문법으로 나뉜다 철자 규칙이나 문법 규칙을 어기면 다른 개발자들이 코드를 읽기도 번거롭고 잘 못 이해하는 경우도 발생한다 철자 규칙 패키지, 클래스, 인터페이스, 메서드, 필드, 타입 변수의 이름을 다루며 이 규칙들은 특별한 이유가 없으면 반드시 지켜야 한다 이 규칙을 어긴 API는 사용도 어렵고 유지보수도 어렵다 패키지와 모듈 이름은 각 요소를 점(.)으로 구분해서 계층적으로 짓는다 요소들은 모두 소문자 알파벳이나 숫자로 이루어진다 조직 바깥에서도 사용될 패키지는 조직의 도메인 이름을 역순으로 사용한다 ex) edu.cmu, ..