JAVA/Effective Java
규칙 64 - 실패 원자성 달성을 위해 노력하라.
예외가 발생한 다음에도 기존에 사용하던 객체의 상태가 그대로 유지되는 것이 좋다.쉽게 이야기하면, 메서드 호출이 정상적으로 처리되지 못한 객체의 상태는 메서드 호출 전 상태와 동일해야한다. 이런 속성을 만족하는 메서드는 실패 원자성(failure atomicity)을 갖추었다고 한다. 이런 실패원자성을 해소하기 위한 방법을 알아보자. 먼저 간단하게 변경 불가능 객체로 설계하는 것이다.-> 왜냐하면 원자성이 있는 객체는 생성된 이후에는 변경되지 않기 때문에 오류가 발생한다고 해도 원자성이 깨지지 않는다. 그럼 변경 가능한 객체의 경우 어떻게 해야할까?-> 이는 실제 연산을 수행하기전에 인자 유효성을 미리 검사하는 방법이다. (객체가 변경되기 전에 예외를 발생시켜 발생하는 것을 막는것이다.) 아래 예를 살펴..
규칙 63 - 어떤 오류인지를 드러내는 정보를 상세한 메시지에 담으라.
개발을 진행하다보면 예기치 못한 상황에서 에러가 자주 발생한다. 에러가 발생하는 것을 다 알고 차단할수있다면 정말 바람직한 프로그램이라고 할 수있을 것이다.하지만 그럴수가 없기때문에 에러를 관리하고 효율적으로 에러정보를 전달하는것이 중요하다. 정확한 에러정보를 전달하는것이 빠르게 문제를 해결하는 실마리가 될것이다.그래서 에러가 발생되었을 때 오류의 상세 메시지에 예외에 관련된 모든 인자와 필드값을 포함시켜야 한다. 예를 들어, IndexOutOfBounds Exception의 경우 해당 범위를 벗어난 인자값과 하한과 상한값도 포함되어있어야 한다. 그러면 정확히 어떻게 오류가 발생된 것인지 알기가 쉬워진다. 하지만 관련된 데이터를 담는 것이 중요하지만 잘못사용하면 별로 도움이 되지 않을 수 있다.그리고 이..
규칙 62 - 메서드에서 던져지는 모든 예외에 대해 문서를 남겨라.
메서드를 올바르게 사용하려면 메서드에서 던져지는 예외에 대한 설명이 문서에 있어야 한다. 그리고 메서드가 던질수있는 모든 무점검 예외까지 선언할 필요는 없지만 점검지점 예외들과 마찬가지로주의해서 문서로 남겨놓으면 좋다. 특히 Javadoc @throws 태그를 사용해서 메서드에서 발생 가능한 모든 무점검 예외에 대한 문서를 남겨야 한다. 하지만 메서드 선언부의 throws 뒤에 무점검 예외를 나열하지는 말아야 한다. 요약하자면 메서드가 던질 가능성이 있는 모든 예외를 문서로 남겨라. 점검지점 예외, 무점검 예외도 남겨라. 이를 지키지 않으면 해당 API를 사용하는 다른사람들이 효과적으로 사용하는게 어려워진다. 출처 : 조슈아 블로크, 『 Effective Java 2/E』, 이병준 옮김, 인사이트(201..
규칙 61 - 추상화 수준에 맞는 예외를 던져라
메서드가 하는 일과 관련성이 없는 예외가 메서드에서 발생하면 디버깅하기 어렵거나 관리하기 어려울 수 있다. 이는 추상화 수준이 낮은 곳에서 발생한 예외를 그대로 밖으로 전달하면 이런일이 발생한다. 이런 문제를 해결하기 위해서 상위계층에서는 하위계층에서 발생하는 예외를 반드시 받아서 상위 계층 추상화 수준에 맞는 예외로 바꿔서 던져야한다. 이를 예외 변환(exception translation)이라고 한다. 예를 들어 몇가지 사례를 살펴보자. 우선 AbstractSequentialList 클래스를 살펴보자. 이 클래스의 get 메서드의 명세를 보면 예외가 발생되었을 때 예외 변환을 해서 보내달라는 것을 확인할 수 있다. 12345678910111213141516 /** * Returns the elemen..
규칙 60 - 표준 예외를 사용해라
예외를 사용할 때 기존에 정의되어있는 표준예외를 사용하는 것이 좋다. 그 이유는 다음과 같다. - 배우기 쉽고 사용하기 편리한 API를 만들수 있으며 다른 프로그래머들도 친숙한 널리 퍼진 관습을 따르기 때문이다. - 잘모르는 예외가 없어 API 가독성을 높일수있다. - 예외클래스를 별도로 만들어서 클래스를 늘리지 않으면 프로그램의 메모리 요구량이 줄어들고 클래스를 로딩하는 시간도 줄어든다. 대표적인 표준 예외 예외용례lllegalArgumentExceptionnull이 아닌 인자값이 잘못되었을때llegalStateException객체 상태가 메서드 호출을 처리하기에 적절치 않을때NullPointerExceptionnull 값을 받으면 안 되는 인자에 null이 전달되었을 때IndexOutOfBoundsE..
규칙 59 불필요한 점검지정 예외 사항은 피하라.
점검지점 예외 (checked error) 은 프로그래머에게 예외상황을 처리하도록 강제함으로써 안전성을 키울수있다. 하지만 모든것이 넘치면 부족하니 못한것처럼 점점지점 예외도 너무 남발하면 사용하기 불편한 API가 될수있다. 다음과 같은 경우를 예를 들어보자 12345try { obj.action(args);catch (Exception e) { ....}cs 만약 위에 코드에서 예외가 발생되지 않도록 미리 체크하는 부분이 있으면 굳이 점검지점예외를 사용하지 않아도된다. 12345if (obj.check(args)) { obj.action(args);} else { ...}cs 이렇게 리팩터링을 사용하면 좀더 유연하게 사용가능한 API가 될 것이다. 하지만 이런경우처럼 리팩터링을 진행할 수 없는 경우가 ..
규칙 58 복구가능 상태에는 점검지정 예외를 사용하고, 프로그래밍 오류에는 실행시점 예외를 이용하라.
자바에는 몇 가지에 throwable을 제공한다. 점검지정 예외 (checked error) 컴파일 시점에 예외가 발생하는 부분으로 컴파일 시에 에러를 처리하는 코드를 삽입하지 않으면 컴파일이 되지 않는다. 12345678910public void ioOperation(boolean isResourceAvailable) { try { if (!isResourceAvailable) { throw new IOException(); } } catch(IOException e) { // Handle caught exceptions. }} Colored by Color Scriptercs unchecked error 컴파일 시점에 체크되지 않는 에러 실생시점 예외(runtime exception)와 오류(erro..
규칙 57 예외는 예외적 상황에만 사용하라.
예외는 잘 사용하면 프로그램의 가독성, 안전성, 유지보수성을 모두 향상시킬 수 있다. 그러나 제대로 사용하지 않으면 반대 효과를 낼 수있다. 다음의 예를 보자. 12345678910111213141516171819202122232425262728public class Main { public static void main(String args[]) { int i = 0; Test[] data = new Test[] {new Test("t1"), new Test("t2")}; try { while(true) { System.out.println(data[i++].getData()); } } catch (ArrayIndexOutOfBoundsException ex) { } } static class Test..
규칙 56 - 일반적으로 통용되는 작명 관습을 따르라
자바의 작명관습은 두 가지 범주로 나눌 수 있다. 철자. -> 패키지, 클래스, 인터페이스, 메서드, 필드 그리고 자료형 변수에 관한 것 -> 아주 그럴듯한 이유가 없이 이 규칙을 어겨서는 안 된다. 1). 패키지 -> 마침표를 구분점으로 사용하는 계층적 이름 이어야 한다. -> 각각의 컴포넌트는 알파벳 소문자로 구성하고, 숫자는 거의 사용하면 안된다. -> 패키지 시작은 회사 조직의 도메인으로 시작한다. com.wedul -> 패키지명 컴포넌트는 짧아야 하며, 8자리 이하여야 한다. -> 약어를 사용하여 의미를 충분히 전달할 수 있어야한다. 2). 클래스, 인터페이스, Enum -> 하나이상의 단어로 구성된다. -> 각 첫 글자는 대문자로 시작해야 하며 널리 사용 되는 약어를 제외하고는 약어를 사용해서..
규칙 55 - 신중하게 최적화하라
모든 프로그래머가 알아둬야 하는 최적화에 관련된 격언이 있다. 1. 맹목적인 어리석음을 비롯한 다른 어떤 이유보다도, 효율성이라는 이름으로 저질러지는 죄악이 더 많다. 2. 97%는 효율성을 잊어버려라. 섣부른 최적화는 모든 악의 근원이다. 그리고 프로그램을 작성하면서 기준을 삼아야 할 내용에 대해 소개한다. [기준] 빠른 프로그램을 만들려고 처음부터 노력하지말고, 좋은 프로그램을 만들려 노력하라. -> 좋은 구조를 가진 프로그램은 빠른게 변경하는데 어렵지 않다. -> 정보은닉의 원칙을 지키는 것이 좋은 구조를 갖는것에 첫 번째 항목이다. 설계를 할 떄는 성능을 제약할 가능성이 있는 결정들을 피하라. -> 특히 통신 API, 프로토콜 정의서는 변경하기 어렵기 때문에, 신중하게 코딩해야한다. API를 설계..