기록하는 습관

메서드가 던지는 예외는 그 메서드를 사용하는데 아주 중요한 정보다. 따라서 각 메서드가 던지는 예외를 문서화하는 것은 중요하며 충분한 시간을 쏟아야 한다. 검사 예외는 따로따로 선언하자 검사 예외는 항상 따로따로 선언하고, 각 예외가 발생하는 상황을 자바독의 @throws 태그를 활용해 정확히 문서화 하자. 공통 상위 클래스 하나로 통합해서 선언하는 일은 삼가야 한다. 극단적인 예로, Exception이나 Throwable을 던진다고 선언해서는 안 된다. 메서드 사용자에게 각 예외에 대처할 수 있는 힌트를 주지 못할뿐더러, 같은 맥락에서 발생할 수 있는 다른 예외들까지 모두 삼켜버려 API 사용성을 크게 떨어트린다. 잘못된 사용 방법 // 잘못 선언한 예 public void testMethod() th..

수행하려는 일과 관련 없는 예외가 나오면 당황스럽기 마련이다. 이는 메서드가 저수준 예외를 처리하지 않고 바깥으로 전파(throw)할 때 종종 일어나는 문제이다. 내부 구현 방식을 드러내어 윗 레벨 API를 오염시킬 수 있고, 구현 방식을 바꾸면 다른 예외가 튀어나와 기존 클라이언트 프로그램을 깨지게 할 수도 있다. 상위 계층에서 예외 번역을 하자 예외 번역이란 상위 계층에서 저수준 예외를 잡아 자신의 추상화 수준에 맞는 예외로 바꾸는 것을 말한다. 위에서 언급한 문제점을 피하기 위해서는 상위 계층에서의 예외 번역이 필요하다. try { ..// 저수준 추상화를 이용 } catch (LowerLevelException e) { // 추상화 수준에 맞게 번역 throw new HigherLevelExcep..

코드를 재사용하듯 예외도 재사용하는 것이 좋다. 자바 라이브러리는 대부분 API에서 충분한 수의 예외를 제공하고 있다. 그러니 가능한 표준 예외를 재사용하자. 표준 예외의 장점 1. 다른 사람이 익히고 사용하기 쉬워진다. 표준 예외를 사용하면 이미 많은 사람들에게 익숙해진 규약을 그대로 따르기 때문에 다른 사람들이 익히고 사용하기 쉬워진다. 2. 읽기 쉬워진다. 낯선 예외보다는 익숙한 예외를 사용하므로 읽기 쉬워지고 예외를 빠르게 파악할 수 있다. 3. 메모리 사용량과 클래스 적재 시간이 줄어든다. 표준 예외를 사용하면 예외 클래스를 별도로 만들지 않아도 된다. 따라서 메모리 사용량과 클래스 적재 시간이 줄어든다. 가장 많이 사용되는 표준 예외 NullPointerException null을 허용하지 않..

검사 예외를 잘 활용하면 프로그램의 안정성과 질을 높일 수 있다. 하지만 검사 예외를 과하게 사용하면 오히려 사용하기 불편한 API가 될 수 있다. 검사 예외와 비검사 예외 선택 기준 API를 제대로 사용해도 발생할 수 있는 예외 거나, 프로그래머가 의미 있는 조치를 취할 수 있는 경우라면 검사 예외를 그렇지 않다면 비검사 예외를 사용하자. 검사 예외 회피 방법 - 비검사 예외 아래의 코드는 API 사용자가 검사 예외를 처리하는 사례이다. // 비검사 예외를 호출한다. } catch (TheCheckedException e) { throw new AssertionError(); } // 에러 스택 코드를 출력하고 시스템을 종료한다. } catch (TheCheckedException e) { e.prin..

자바에서 문제 상황을 알리는 타입(throwable)으로는 검사 예외(checked Exception), 런타임 예외(Runtime Exception), 에러 이렇게 3가지를 제공한다. 언제 무엇을 사용해야 하는지 참고하면 좋은 지침들에 대해 알아보자. 검사 예외와 비검사 예외를 구분하는 기본 규칙 호출하는 쪽에서 복구하리라 예상되는 상황이라면 검사 예외를 사용하자. 검사 예외를 던지면 호출자가 그 예외를 catch로 처리하거나, 더 바깥으로 전파하도록 강제된다. 따라서 메서드 선언에 포함되는 예외는 해당 메서드를 호출했을 때 발생할 수 있는 유력한 결과를 나타낸다. 즉, API 설계자는 API 사용자에게 검사 예외(checked Exception)를 넘겨주어 그 상황에서 복구하라고 요구한 것이다. 따라..

예외는 예외 상황에서 쓸 의도로 설계되었다. 정상적인 제어 흐름에서 사용해서는 안되며, 이를 강요하는 API도 만들면 안 된다. 예외를 제어 흐름용으로 사용하지 말자 위 코드는 무한루프를 돌다가 배열의 끝에 도달해 ArrayIndexOutOfBoundsException이 발생하면 배열 순회를 끝낸다. 제어 흐름용으로 예외를 사용한 케이스이다. // 예외를 완전히 잘못 사용한 예 try { int i = 0; while(true) { range[i++].climb(); } } catch (ArrayIndexOutOfBoundsException e) { } 위 코드는 직관적이지 않아 무슨 일을 하는지 한눈에 알아보기 어렵다. 또한, 다른 문제점들도 존재한다. 예외를 제어 흐름용으로 사용하면 표준 관용구보다 ..

자바 플랫폼은 명명 규칙이 잘 정립되어 있으며, 대부분 자바 언어 명세(JLS)에 기술되어 있다. 자바의 명명 규칙은 크게 철자와 문법 두 범주로 나뉜다. 1. 자바의 명명 규칙 - 철자 철자 규칙은 패키지, 클래스, 인터페이스, 메서드, 필드, 타입 변수의 이름 등을 다룬다. 이 규칙을 어긴 API는 사용하기 어려우며 유지 보수하기도 어렵다. 또한, 코드를 읽기 번거로워지고 다른 뜻으로도 오해할 수 있으므로 반드시 따르는 것이 좋다. 패키지, 모듈 (.)으로 구분하여 계층적으로 짓는다. 소문자 알파벳으로 구성되며, 드물게 숫자가 들어가기도 한다. 바깥에서도 사용하는 패키지라면 도메인의 역순으로 구성한다. 각 요소는 8자 이하의 짧은 단어를 사용한다. util 처럼 의미가 통하는 약어를 사용하는 것도 좋..

섣불리 최적화를 진행하면 좋은 결과보다 해로운 결과로 이어지기 쉽다. 빠르지도 않고 제대로 동작하지 않으면서 수정하기 어려운 소프트웨어가 될 수 있는 것이다. 우리는 빠른 프로그램보다 좋은 프로그램을 만들어야 한다. 좋은 프로그램은 개별 구성요소의 내부를 독립적으로 설계할 수 있다. 따라서 시스템의 나머지에 영향을 주지 않고도 각 요소를 다시 설계할 수 있다. 좋은 프로그램을 만들었지만 성능이 나오지 않는다면 그 아키텍처가 최적화할 수 있는 길을 안내해줄 것이다. 설계 단계에서 성능을 고려하자 프로그램의 구현상의 성능 이슈는 나중에 최적화로 해결할 수 있지만, 아키텍처의 결함이 성능을 해치는 상황이라면 시스템 전체를 다시 만들지 않고서는 해결 불가능할 수도 있다. 완성된 설계의 기본 틀을 변경하려다 보면..

자바 네이티브 인터페이스는 자바 프로그램이 C나 C++같은 네이티브 프로그래밍 언어로 작성한 메서드를 호출하는 기술이다. 이러한 네이티브 메서드를 사용하려면 한번 더 생각하고 신중히 사용해야 한다. 네이티브 메서드가 주로 사용된 경우 1. 윈도우 레지스트리 같은 플랫폼 특화 기능을 사용한다. 2. 네이티브 코드로 작성된 기존 라이브러리를 사용한다. 3. 성능 개선을 목적으로 성능에 결정적 영향을 주는 부분만 따로 네이티브 언어로 작성한다. 네이티브 메서드를 권장하지 않는 이유 1. 자바가 성숙해지면서 플랫폼의 기능들을 흡수하고 있다. 플랫폼 특화 기능을 사용하려면 네이티브 메서드가 필요하다. 하지만 자바 언어가 발전해가면서 OS와 같은 하부 플랫폼의 기능들을 점차 흡수하고 있다. 따라서 네이티브 메서드를..