자바 공부

이 포스팅에서 작성하는 내용은 EFFECTIVE JAVA(이펙티브자바) 에서 발췌하였습니다. 아이템 75. 예외의 상세 메시지에 실패 관련 정보를 담으라 예외를 잡지 못해 프로그램이 실패하면 자바 시스템은 그 예외의 스택 추적(stack trace) 정보를 자동으로 출력한다. 스택 추적은 예외 객체의 toString 메서드를 호출해 얻는 문자열로, 보통은 예외 클래스 이름 뒤에 상세 메시지가 붙는 형태다. 에외의 toString 메서드에 실패 원인에 관한 정보를 가능한 한 많이 담아 반환하는 일이 중요하다. 예외 메시지 팁 실패 순간을 포착하려면 발생한 예외에 관여된 모든 매개변수와 필드의 값을 실패 메시지에 담아야 한다. 예컨데, IndexOutOfBoundsException의 상세 메시지는 범위의 최..

이 포스팅에서 작성하는 내용은 EFFECTIVE JAVA(이펙티브자바) 에서 발췌하였습니다. 아이템 74. 메서드가 던지는 모든 예외를 문서화하라 검사 예외 문서화 메서드가 던지는 예외는 그 메서드를 올바로 사용하는데 필요한 정보다. 검사 예외는 항상 따로 선언하고, 각 예외가 발생하는 상황을 자바독의 @throws 태그를 사용하여 정확히 문서화하자. 공통 상위 클래스 하나로 뭉뜽그려 선언하는 것은 좋지 않다. 메서드 사용자에게 각 예외에 대처 방안을 줄 수 없다. 같은 맥락에서 발생할 여지가 있는 다른 예외들까지 삼켜버릴 수 있어 API 사용성을 크게 떨어뜨린다. 이 규칙에 유일한 예외는 main 메서드다. (main은 오직 JVM만 호출하기 때문) 비검사 예외 문서화 자바 언어가 요구하는 것은 아니지..

이 포스팅에서 작성하는 내용은 EFFECTIVE JAVA(이펙티브자바) 에서 발췌하였습니다. 아이템 73. 추상화 수준에 맞는 예외를 던지라 수행하려는 일과 관련 없어 보이는 예외가 튀어나오는 경우가 있는데, 메서드가 저수준 예외를 처리하지 않고 바깥으로 전파해버릴 때 종종 일어나는 일이다. 이는 단순히 프로그래머를 당황시키는 데 그치지 않고, 내부 구현 방식을 드러내어 윗 레벨 API를 오염시킨다. 다음 릴리스에서 구현 방식을 바꾸면 다른 예외가 튀어나와 기존 클라이언트 프로그램을 깨지게 할 수도 있는 것이다. 이 문제를 피하려면 상위 계층에서는 저수준 예외를 잡아 자신의 추상화 수준에 맞는 예외로 바꿔 던져야 한다. (= 예외 번역) ex 1) 예외 번역 try { ... // 저수준 추상화를 이용한..

이 포스팅에서 작성하는 내용은 EFFECTIVE JAVA(이펙티브자바) 에서 발췌하였습니다. 아이템 72. 표준 예외를 사용하라 숙력된 프로그래머는 그렇지 못한 프로그래머보다 더 많은 코드를 재사용하듯, 예외도 재사용하는 것이 좋으며 자바 라이브러리는 대부분 API에서 쓰기에 충분한 수의 예외를 제공한다. 표준 예외 표준 예외를 재사용하면 얻는 게 많다. 개발자의 API가 다른 사람이 익히고 사용하기 쉬워진다. (많은 프로그래머에게 이미 익숙해진 규약을 그대로 따르기 때문) 예외 클래스 수가 적을수록 메모리 사용량도 줄고 클래스를 적재하는 시간도 적게 걸린다. Exception, RuntimeException, Thorwable, Error는 직접 재사용하지 말자. 이 클래스들은 추상 클래스라고 생각하는..

이 포스팅에서 작성하는 내용은 EFFECTIVE JAVA(이펙티브자바) 에서 발췌하였습니다. 아이템 71. 필요 없는 검사 예외 사용은 피하라 검사 예외 검사 예외는 발생한 문제를 프로그래머가 처리하여 안정성을 높일 수 있게 해준다. 검사 예외를 과하게 사용하면 오히려 쓰기 불편한 API가 될 수 있다. 어떤 메서드가 검사 예외를 던질 수 있다고 선언됐다면, 이를 호출하는 코드에서는 catch 블록을 두어 그 예외를 붙잡아 처리학나 더 바깥으로 던져 문제를 전파해야만 한다. 어느 쪽이든 API사용자에게 부담을 준다. API를 제대로 사용해도 발생할 수 있는 예외이거나, 프로그래머가 의미있는 조치를 취할 수 있는 경우라면 이러한 단점을 감수하고도 사용하는 것이 좋고, 둘 중 어디에도 속하지 않는다면 비검사..

이 포스팅에서 작성하는 내용은 EFFECTIVE JAVA(이펙티브자바) 에서 발췌하였습니다. 아이템 70. 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라 자바는 문제 상황을 알리는 타입(throwable)으로 검사 예외, 런타임 예외, 에러 3가지가 있다. 검사 예외 호출하는 쪽에서 복구하리라 여겨지는 상황이라면 검사 예외를 사용하자. 이것이 검사와 비검사 예외를 구분하는 기본 규칙이다. 검사 예외를 던지면 호출자가 그 예외를 catch로 잡아 처리하거나 더 바깥으로 전파하도록 강제하게 된다. 따라서 메서드 선언에 포함된 검사 예외 각각은 그 메서드를 호출했을 때 발생할 수 있는 유력한 결과임을 API 사용자에게 알려주는 것이다. 비검사 예외 비검사 예외(throwab..

이 포스팅에서 작성하는 내용은 EFFECTIVE JAVA(이펙티브자바) 에서 발췌하였습니다. 아이템 69. 예외는 진짜 예외 상황에만 사용하라 ex 1) 예외를 잘못 사용한 예 try { int i = 0; while (true) range[i++].climb() } catch (ArrayIndexOutOfBoundsException e) { } 위 코드는 배열의 원소를 순회하는데, 무한루프로 돌다가 배열의 범위를 벗어나 ArrayIndexOutOfBoundsException이 발생하면 끝을 낸다. 이 코드는 상당히 가독성도 떨어지고 성능도 좋지 않다. ex 2) ex1을 기반으로 표준적인 관용구대로 작성한 예 for(Mountain m : range) m.climb(); 예외를 사용한 반복문을 사용하지..

이 포스팅에서 작성하는 내용은 EFFECTIVE JAVA(이펙티브자바) 에서 발췌하였습니다. 아이템 68. 일반적으로 통용되는 명명 규칙을 따르라 자바의 명명 규칙 자바 플랫폼은 명명 규칙이 잘 정립되어 있으며, 자바 언어 명세에 기술되어 있다. 자바 명명 규칙은 크게 철자와 문법으로 나뉜다. 철자 패키지, 클래스, 인터페이스, 메서드, 필드, 타입 변수의 이름을 다룬다. 이 규칙들은 특별한 이유가 없는 한 반드시 따라야한다. 이 규칙을 어기면 가독성이 떨어져 그로 인해 오류를 발생시킬 수도 있다. 패키지와 모듈 패키지와 모듈 이름은 각 요소를 점(.)으로 구분하여 계층적으로 명명한다. 요소들은 모두 소문자 알파벳 혹은 숫자로 이루어진다. 조직 바깥에서도 사용될 패키지라면 조직의 인터넷 도미인 이름을 역..