본문 바로가기
[Effective Java] 하위 계층의 예외 처리를 신중하게 하자. [Effective Java] 하위 계층의 예외 처리를 신중하게 하자. - 상위 계층에서 하위 계층의 예외를 반드시 catch 해야 한다. 그리고 그 예외대신에 상위 계층의 추상체가 알 수 있는 예외로 바꿔 던져야 한다. 이 이디엄을 예외 변환(exception translation)이라 한다. 그렇지 않으면 구현 내용을 공개하는 것처럼 되어 나중에 호환성 이슈를 겪게 된다. - 만약 예외 변환을 사용하면서 근본적인 이유까지 확실히 알고 싶다면 변화할 때 excpetion 을 담아서 전달할 수 있다. 예를 들어 throw new HigherLevelException( lowerLevelException ) - 예외 연쇄 - 하위 계층(저수준)에서 발생한 예외를 분별 없이 전파하는 것보다는 예외 변환을 사.. 2017. 2. 27.
[Effective Java] 표준 예외를 사용하자 [Effective Java] 표준 예외를 사용하자 - 기본 예외를 재사용하면 여러 가지 장점이 있다. 프로그래머들이 이미 익숙해진 내용과 일치하기 때문에 우리 API 를 배우고 사용하기 쉽게 해준다. 생소한 예외를 사용하지 않으므로 코드를 이해하기 쉽다. 메모리 사용도 적게하고 클래스를 메모리로 로딩하는 시간도 줄어든다. - 자주 재사용되는 형태의 exception 은 IllegalArgumentException, IllegalStateException, NullPointerException, UnSupportedOperationException 등이 있다. API, Effective JAVA, IllegalArgumentException, illegalstateexception, NullPointer.. 2017. 2. 24.
[Effective Java] checked 예외의 불필요한 사용을 피하자 [Effective Java] checked 예외의 불필요한 사용을 피하자 - checked 예외는 프로그래머가 예외 상황을 처리하지 않을 수 없도록 한다. - checked 예외의 과용은 API 사용자를 불편하게 만든다. - 만일 API 사용자가 해당 예외 사항에 대해 ignore 와 같은 방식 이외에 해결방법이 없다면, unchecked 에러를 사용하는 게 더 적합하다. - checked 예외를 unchecked 예외로 바꾸는 한 가지 방법은, 해당 예외를 발생시키는 메소드를 두 개의 메소드로 쪼개는 것이다. 그 중 첫번째 메소드에서는 예외가 생겼는지를 나타내는 boolean 값을 반환하게 한다. 예를 들면.. try{obj.action(args);} catch( TheCheckedException .. 2017. 2. 23.
[Effective Java] 복구 가능 상황에서는 checked 예외를 사용하고, 런타임 예외는 프로그램 에러에 사용하자. 복구 가능 상황에서는 checked 예외를 사용하고, 런타임 예외는 프로그램 에러에 사용하자. - 자바 언어는 다음 세 종류의 예외를 던질 수 있다. checked exception, runtime exception, error - 메소드 호출자가 당연히 예외 복구를 할 수 있는 상황에서는 checked 예외를 사용하자. checked 예외를 던지면 그 메소드 호출자가 catch 문에서 예외를 처리하거나 또는 외부로 넘겨야 한다. API 사용자가 checked 예외와 만났다는 것은, 그런 상황을 복구하라는 지시를 그 API 설계자로부터 받은 것이다. - unchecked exception 인 runtime exception 과 error 는 catch 할 필요가 없고, 일반적으로 catch 해서도 안 된.. 2017. 2. 21.
[Effective Java] 예외 상황에서만 예외를 사용하자. [Effective Java] 예외 상황에서만 예외를 사용하자. - 예외는 예외 상황을 대비해 설계된 것이므로, JVM 을 만드는 회사가 예외 처리 속도를 빠르게 하려고(우리가 명시적으로 검사하는 것만큼) 매달릴만한 일이 아니다. try-catch 블록 내부에 코드를 넣으면, 여러 종류의 JVM 이 해 줄 수 있는 나름의 최적화를 못하게 하는 부작용이 생길 수 있다. 배열을 반복 루프 처리하면서 정상적인 루프 종료 검사를 하는 표준 이디엄 코드가 반드시 중복 검사를 하는 것은 아니다. 근래의 JVM들에서는 그런 코드를 최적화한다. - 예외는 예외적인 상황에서만 사용해야 한다. 절대로 정상적인 흐름 제어에 사용하면 안된다. - 잘 설계된 API에서는 클라이언트가 예외를 사용해서 정상적인 흐름 제어를 하게끔.. 2017. 2. 20.
[Effective Java] 보편화된 작명 규칙을 따르자. [Effective Java] 보편화된 작명 규칙을 따르자. - 패키지 이름은 짧게 하되, 일반적으로 9자 이내의 문자가 좋다. awt와 같이 복합 단어의 첫 자를 딴 두문자나, util 과 같은 약어를 사용해도 좋다. - 타입 매개변수의 이름은 통상적으로 단일 문자이며, 대부분 다음 다섯 개 중 하나이다. 임의 타입은 T, 컬렉션 요소 타입은 E, Map 의 키와 값은 K, V, 예외는 X 임의 타입의 순차는 T에 이어 U, V 또는 T1, T2, T3 등과 같이 하기도 한다. - boolean 이 아닌 속성을 반환하는 메소드의 이름은 명사, 명사구, 또는 동사인 get 으로 시작하는 동사구로 구성한다. size, hashCode, getTime 등이 그 예이다. 이런 return 값이 있는 메소드들은.. 2017. 2. 17.
[Effective Java] 잘 판단해서 최적화하자 [Effective Java] 잘 판단해서 최적화하자 - 최적화에 대한 명언이 있다. 더 많은 컴퓨팅 죄악이 다른 어떤 한 가지 이유(무지로 인한 어리석음을 포함해서)보다는 효율성(달성이 안 되는)의 이름으로 저질러진다. 사소한 효율성은 잊어야 한다. 97%의 시간에 대해 논하자. 성급한 최적화는 모든 죄악의 근원이다. 최적화에 관한 두 가지 규칙을 따르자. 규칙 1. 하지 말자. 규칙 2. (전문가에 한해서). 아직 하지 말자. 정말 최적화되지 않은 솔루션이 있을 때까지는. - 성급한 최적화는 얻는 것보다 잃는 것이 더 많기 쉽다. 최적화를 하면서 빠르지도 않고 제대로 동작하지도 않으며, 문제를 쉽게 해결하기도 어려운 소프트웨어를 만들기도 쉽다. - 성능 때문에 훌륭한 아키텍쳐 원리를 포기하지 말자. .. 2017. 2. 16.
[Effecitve Java] 네이티브 메소드를 분별력 있게 사용하자. [Effecitve Java] 네이티브 메소드를 분별력 있게 사용하자. - JNI 는 네이티브 메소드를 호출할 수 있게 해준다. 네이티브 메소드는 C, C++ 과 같은 네이티브 프로그래밍 언어로 작성한 특별한 메소드를 말한다. - 지금까지 네이티브 메소드의 주용도는 세가지였다. 레지스트리와 파일 락 같은 특정 플랫폼 관리시스템의 접근을 제공 레거시 데이터를 제공할 수 있는 레거시 코드로 된 라이브러리의 접근 제공 성능 향상을 위해 어플리케이션의 일부를 네이티브 언어로 작성하는 데 사용 - 자바가 발전하면 기존의 네이티브 메소드만이 할 수 있었던 일을 많이 대체하였다. java.util.prefs 패키지가 레지스트리 기능을 제공. java.awt.SystemTray 가 데스크톱 시스템의 휴지통 영역의 접근.. 2017. 2. 14.
[Effecitve Java] 리플렉션보다는 인터페이스를 사용하자. [Effecitve Java] 리플렉션보다는 인터페이스를 사용하자. - 리플렉션은 여러모로 강력한 기능을 제공한다. 하지만 이런 강력함은 다음의 대가들을 수반한다. 컴파일 시점에 가능한 타입 확인의 장점이 없어진다. 재귀적인 접근을 필요로 하는 코드는 알아 보기 어렵고 길다. 처리 성능이 늦다. - 사실 리플렉션은 컴포넌트 기반의 어플리케이션 개발 도구용으로 설계되었다. 따라서 일반적으로 런타임에서는 리플렉션을 이용해서 재귀적으로 사용하면 안된다. - 리플렉션이 필요한 복잡한 애플리케이션은 다음과 같다. 클래스 브라우저 객체 조사기 코드 분석 도구 RPC - 리플렉션을 지극히 제한된 형태로만 사용하여 비용이 거의 수반되지 않도록 한다면 리플렉션의 많은 장점을 얻을 수 있다. 예를 들어 컴파일 시점에는 쓸.. 2017. 2. 13.
반응형