sinau

메서드가 던지는 예외를 모두 문서화하는 것이 좋습니다. 검사 예외는 항상 따로 선언하며, 예외가 발생하는 상황을 자바독의 @throws태그를 이용해 정확하게 문서화합니다. 이때 주의할 점은 아래와 같이 공통 상위 클래스 하나로 뭉뚱그려 선언하지 않는 것입니다. /** * @throws Exception */ public void doSomething() throws Exception { // doSomething } 이는 메서드 사용자에게 예외에 대처할 수 있는 힌트를 주지 못할뿐더러 같은 맥락에서 발생할 여지가 있는 다른 예외들 까지 삼켜버릴 수 있기 때문에 API 사용성을 크게 떨어뜨립니다. 비검사 예외도 문서화하면 좋습니다. 하지만 메서드 선언의 throws목록에는 넣지 않아야 합니다. 비검사 예외..

메서드가 저수준 예외를 처리하지 않고 바깥으로 throw 해버릴 때 상위 메서드에서는 해당 메서드와 관련없는 예외가 발생하여 당황스러울 수 있습니다. 이는 내부 구현방식을 상위에 드러내어 상위 레벨 API를 오염 시킬 수 있고, 다음 릴리스에서 구현방식이 변경되면 다른 예외가 튀어나와 기존 클라이언트 프로그램을 깨지게 할 수도 있습니다. 예외 번역 상위 계층에서는 저수준 예외를 잡아 자신의 추상화 수준에 맞는 예외로 바꿔 던져야 합니다. try { ... // 저수준 추상화를 이용합니다. } catch (LowerLevelException e) { // 추상화 수준에 맞게 번역합니다. throw new HigherLevelException(...); } 예외 연쇄 저수준 예외가 디버깅에 도움이 된다면 예..

표준 예외 재사용의 장점 다른 사람이 API를 익히고 사용하기 쉬워집니다. 낯선 예외를 사용하지 않으므로 코드의 가독성이 높아집니다. 예외 클래스의 수가 적을수록 메모리 사용량도 줄고 클래스 로딩시간도 줄어듭니다. 많이 사용되는 예외 IllegalArgumentException 메서드의 파라미터로 부적절한 값이 들어왔을 때 던지는 예외입니다. null이 들어오면 관례상 NullPointerException 예외를 사용합니다. 시퀀스 허용범위를 넘기는 경우 IndexOutOfBoundsException 예외를 사용합니다. IllegalStateException 객체의 상태가 호출된 메서드의 수행에 부적합할 때 사용합니다.(초기화되지 않은 객체를 사용하려 할 때) ConcurrentModificationEx..

검사예외는 제대로 활용한다면 API와 프로그램의 질을 높일 수 있습니다. 하지만 검사 예외를 과도하게 사용하면 오히려 사용하기 불편한 API될 수 있습니다. 검사예외 회피방법 1. 비검사 예외 API를 제대로 사용해도 발생할 수 있는 예외거나, 프로그래머가 의미있는 조치를 취할 수 있는 경우가 아니라면 비검사 예외를 사용하는 것이 좋습니다. } catch (TheCheckedException e) { throw new AssertionError(); } } catch (TheCheckedException e) { e.printStackTrace(); System.exit(); } 위의 두 예제와 같은 경우는 차라리 비검사 예외로 API로 만드는 것이 더 좋습니다 2. Optional 검사 예외를 던지는 ..

검사 예외와 비검사 예외긔 구분 클라이언트에서 복구할거라 여겨지는 상황이면 검사예외를, 그렇지 않으면 비검사예외를 사용합니다. 검사 예외의 특징 대표적으로 Exception 클래스가 있습니다. 메서드 선언에 포함된 검사 예외들은 메서드를 호출했을 때 발생할 수 있는 유력한 결과임을 API 사용자에게 알려주고 이를 강제합니다. 비검사 예외의 특징 대표적으로 RuntimeExcpeiton 클래스가 있습니다. 프로그램내에서 catch할 필요가 없거나, catch 하지 말아야 하는 예외입니다. 프로그램이 비검사 예외를 던졌다는 것은 복구 불가능하거나 실행해봤자 득보다는 실이 많다는 뜻입니다.

예외는 오직 예외 상황에서만 써야합니다. 절대로 일상적인 제어 흐름용으로 쓰여선 안됩니다. 잘 설계된 API라면 클라이언트가 정상적인 제어 흐름에서 예외를 사용할 일이 없어야합니다.

패키지 명명 규칙 패키지와 모듈 이름은 각 요소를 점(.)으로 구분하여 계층적으로 짓습니다. 요소들은 모두 소문자 알파벳 혹은 숫자를 사용합니다. 패키지를 설명하는 하나 이상의 요소로 이루어져야 합니다. 일반적으로 8자 이하의 짧은 단어로 이름을 짓습니다. 클래스, 인터페이스 하나 이상의 단어로 구성하며, 첫 글자는 무조건 대문자로 작성합니다. 여러 단어의 첫글자만 딴 약자나 널리 통용되는 줄임말을 제외하고는 줄이지 않습니다. HttpUrl의 URL과 같은 약자의 경우 대부분은 첫 글자만 대문자로 사용합니다. 메서드, 필드 첫 글자를 소문자로 쓴다는 점만 제외하면 클래스 명명 규칙과 동일합니다. 첫 단어가 약자라면 단어 전체가 소문자입니다. 상수 구성하는 단어 모두 대문자로 쓰며 단어 사이는 밑줄로 구분..

그 어떤 핑계보다 효율성이라는 이름 아래 행해진 컴퓨팅 죄악이 더 많다. - 윌리엄 울프 자그마한 효율성은 모두 잊자. 섣부른 최적화가 만악의 근원이다. - 도널드 크누스 최적화를 할 떄는 다음 두 규칙을 따르라. 첫 번째. 하지 마라. 두 번째, (전문가 한정) 아직 하지마라. 다시 말해, 완전히 명백하고 최적화 되지 않은 해법을 찾을 때까지는 하지 마라. - M. A. 잭슨 빠른 프로그램 보다는 좋은 프로그램(견고한 구조)을 작성하는 것이 더 중요합니다. 성능때문에 견고한 구조를 희생하지 말아야합니다. 또, 성능을 제한하는 설계를 피하는 것이 좋습니다. 특히 API, 네트워크 프로토콜, 파일 데이터를 설계할 때는 성능을 염두해야 합니다. 시스템 구현을 완료 했다면 성능을 측정하고 충분히 빠르지 않다면..

자바 네이티브 인터페이스(Java Native Interface, JNI) 자바 프로그램이 네이티브 메서드(C나 C++같은 네이티브 프로그래밍 언어로 작성한 메서드)를 호출하는 기술입니다. 네이티브 메서드의 사용처 레지스트리 같은 플랫폼 특화 기능을 사용합니다. 네이티브 코드로 작성된 기존 라이브러리를 사용합니다. 성능 개선을 목적으로 결정적인 영향을 주는 영역만 따로 네이티브 언어로 작성합니다. 최근의 자바 JVM의 발전으로 대부분의 작업에서 다른 플랫폼에 견줄만한 성능을 낼 수 있습니다. 그래서 현재는 성능을 개선할 목적으로 네이티브 메서드를 사용하는 것은 거의 권장하지 않습니다. 예를 들어 자바 1.1의 BigInteger는 C로 작성했지만 자바 3때 순수 자바로 다시 구현되면서 원래의 구현보다도 ..

리플렉션의 단점 1. 컴파일 타임 타입 검사가 주는 이점을 누릴 수 없습니다. 2. 코드가 지저분하고 장황해집니다. 3. 성능이 떨어집니다. 리플렉션은 아주 제한된 형태로만 사용합니다. 리플렉션은 인스턴스 생성에만 쓰고, 이렇게 만든 인스턴스는 인터페이스나 상위 클래스로 참조해 사용합니다.