본문 바로가기

전체 카테고리361

[Effective Java] 아이템71 필요 없는 검사 예외 사용은 피하라 ■ 검사 예외의 문제 검사 예외를 남발하면 쓰기 불편한 API가 된다. 어떤 메서드가 검사 예외를 던질 수 있다고 선언 됐다면, 이를 호출하는 코드에서는 catch 블록을 두어 그 예외를 붙잡아 처리하거나 더 바깥으로 던져 문제를 전파해야한다. API 사용자에게 부담을 준다. 검사 예외를 던지는 메서드는 스트림 안에서 직접 사용할 수 없기 때문에 자바 8부터는 부담이 더 커졌다. API를 제대로 사용해도 발생할 수 있거나, 프로그래머가 의미있는 조치를 취할 수 있다면 받아들일 수 있지만, 둘다 해당이 안되면 비검사 예외를 사용하는 게 좋다. 특히 검사 예왹사 프로그래머에게 지우는 부담은 메서드가 단 하나의 검사 예외만 던질 때가 특히 크다. 이미 다른 검사 예외도 던지는 상황에서 또 다른 검사 예외를 추.. 2021. 8. 22.
[Effective Java] 아이템70 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라 ■ 검사 예외와 비검사 예외 / 에러 자바는 문제 상황을 알리는 타입으로(throwable)으로 검사 에외, 런타임 예외, 에러 이렇게 3가지를 제공한다. 예외 종류와 관련해서는 아래 링크를 참고하자. https://insight-bgh.tistory.com/24?category=857504 호출하는 쪽에서 복구하리라 여겨지는 상황이라면 검사 예외를 사용하라. 이것이 검사와 비검사 예외를 구분하는 기본 규칙이다. 검사 예외를 던지면 호출자가 그 예외를 catch로 잡아서 처리하거나 더 바깥으로 전파하도록 강제한다. 비검사 throwable은 두 가지로, 바로 런타임 예외와 에러다. 이 둘은 프로그램에서 잡을 필요가 없거나 보통 잡지 말아야한다. 이런 throwable을 잡지 않은 스레드는 적절한 오류 메.. 2021. 8. 22.
[Effective Java] 아이템69 예외는 진짜 예외 상황에만 사용하라 ■ 예외는 예외 진짜 예외 상황에서만 사용하라 아래 코드는 예외를 잘못 사용한 코드이다. 무한 루프를 돌다가 배열의 끝에 도달해 예외가 발생하면 끝을 내는 코드이다. try { int i = 0; while(true) range[i++].climb(); } catch (ArrayIndexOutOfBoundsException e) { } 반복문에서 배열의 크기보다 커졌는지 검사를 하는 부분을 줄이려고 의도한 코드 였을 텐데, 이는 잘못된 추론이다. 예외는 예외 상황에 쓸 용도로 설계되었으므로 JVM 구현자 입장에서는 명확한 검사만큼 빠르게 만들어야 할 만큼 최적화에 신경쓰지 않았을 확률이 높다. 코드를 try-catch 블록 안에 넣으면 JVM이 적용할 수 있는 최적화가 제한된다. 배열을 순회하는 표준 관.. 2021. 8. 22.
[Effective Java] 아이템68 일반적으로 통용되는 명명 규칙을 따르라 자바 플랫폼의 명명 규칙은 잘 정립되어 있으며, 그중 많은 것이 자바 언어 명세에 기술되어 있다. 자바의 명명 규칙은 크게 철자와 문법, 두 범주로 나뉜다. ■ 패키지와 모듈 이름 조직의 인터넷 도메인 이름을 역순으로 사용한다 (com.google) 예외 적으로 표준 라이브러리와 선택적 패키지들은 각각 java, javax로 시작한다. 패키지 이름의 나머지는 해당 패키지를 설명하는 하나 이상의 요소로 이루어진 8자이하의 짧은 단어로 표현한다. ■ 클래스와 인터페이스 (열거 타입, 애너테이션 포함) 클래스와 인터페이스의 이름은 하나 이상의 단어로 이뤄지면 각 단어는 대문자로 시작한다. 단어를 줄여쓰지 않도록 한다. ■ 메서드와 필드 첫글자를 소문자로 쓴다는 점만 빼면 클래스 명명 규칙과 같다. 객체를 반환.. 2021. 8. 1.
[Effective Java] 아이템67 최적화는 신중히 하라 ■ 최적화 관련 격언 첫번째, 하지 마라. 두 번째, (전문가 한정) 아직 하지 마라. 다시 말해, 완전히 명백하고 최적화되지 않은 해법을 찾을 때까지는 하지마라. 자그마한 효율성은 모두 잊자. 섣부른 최적화가 만악의 근원이다. 이 격언들은 자바가 탄생하기 20년 전에 나온 것으로 최적화의 어두운 진실을 이야기한다. 최적화는 좋은 결과 보다는 해로운 결과로 이어지기 쉽고, 섣불리 진행하면 특히 더 그렇다. 따라서 성능 때문에 견고한 구조를 희생하지 말자. 빠른 프로그램보다는 좋은 프로그램을 작성하라. 좋은 프로그램이지만 원하는 성능이 나오지 않는다면 그 아키텍처 자체가 최적화할 수 있는 길을 안내해줄 것이다. 좋은 프로그램은 정보 은닉 원칙을 따르므로 개별 구성요소의 내부를 독립적으로 설계 할 수 있다... 2021. 8. 1.
[Effective Java] 아이템66 네이티브 메서드는 신중히 사용하라 자바 네이티브 인터페이스는 자바 프로그램이 네이티브 메서드를 호출하는 기술이다. 여기서 네이티브 메서드란 C나 C++ 같은 네이티브 프로그래밍 언어로 작성한 메서드를 말한다. 전통적으로 네이티브 메서드의 주요 쓰임은 다음 세가지 이다. 레지스트리 같은 플랫폼 특화 기능 사용 네이티브 코드로 작성된 기존 라이브러리를 사용 성능 개선을 목적으로 성능에 결정적인 영향을 주는 영역만 따로 네이티브 언어로 작성 성능을 개선할 목적으로 네이티브 메서드를 사용하는 것은 거의 권장하지 않는다. 네이티브 메서드에는 심각한 단점이 있다. 네이티브 언어가 안전하지 않으므로(아이템50) 네이티브 메서드를 사용하는 애플리케이션도 메모리 훼손 오류로부터 더 이상 안전하지 않다. 또한 디버깅도 어렵고, 이식성도 낮으며, 가비지 컬.. 2021. 8. 1.

티스토리툴바