Reference/Effective-Java

[Effective-Java] Chapter10 #70. 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라

📌 throwable Java는 문제 상황을 알리는 타입(throwable)으로 3가지를 제공한다. 검사 예외 비검사 예외(Runtime 예외, Error) 어느정도 참고할만한 지침을 따르는 것이 좋다. 📌 검사 예외 💡 호출하는 쪽에서 복구하리라 여겨지는 상황이라면 검사 예외를 사용하라 기본적으로 "복구할 수 있는 조건"이라는 전제여야 한다. 검사예외를 던지면 호출자가 해당 예외를 catch로 잡아 처리하거나, 더 바깥으로 전파하도록 강제하게 된다. 사용자가 예외를 잡기만 하고 별다른 조취를 취하지 않을 수 있는데 좋지 않은 생각이다. (Item 77) 따라서 메서드 선언에 포함된 검사 예외 각각은 해당 메서드를 호출했을 때 발생할 수 있는 유력한 결과임을 API 사용자에게 알려준다. 📌 비검사 예외 ..

[Effective-Java] Chapter10 #69. 예외는 진짜 예외 상황에만 사용하라

📌 예외를 잘못 사용한 경우 try { int i = 0; while(true) [rangepi++].climb(); } catch (ArrayIndexOutOfBoundsException e) { ... } 직관적이지 않다는 사실만으로도 이렇게 작성해선 안 된다. 잘못된 추론을 근거로 성능을 높이려 했다. (JVM에서 경계를 넘는지 확인하므로 반복문에서도 검사하면 중복일 것이라는 가정) 예외는 예외 상황에만 쓸 용도로 설계되어 JVM 구현자 입장에서 최적화에 별로 신경 쓰지 않았을 가능성이 크다. try-block을 사용하면 JVM이 적용할 수 있는 최적화가 제한된다. 배열을 순회하는 표준 관용구는 중복 검사를 수행하지 않는다. JVM이 알아서 최적화해 없애준다. 예외를 사용한 쪽이 표준 관용구보다 훨..

[Effective-Java] Chapter9 #68. 일반적으로 통용되는 명명 규칙을 따르라

📌 명명 규칙 크게 철자와 문법, 두 범주로 나뉜다. 철자 규칙은 패키지, 클래스, 인터페이스, 메서드, 필드, 타입 변수의 이름을 다룬다. 특별한 이유가 없는 한 반드시 따라야 한다. 이 규칙을 어긴 API는 사용이 어렵고, 유지보수가 힘들다. 문법 규칙은 좀 더 유연하고 논란도 많다. 📌 철자 규칙 식별자 타입 예 패키지와 모듈 org.junit.jupiter.spi, com.google.common.collect 클래스와 인터페이스 Stream, FutureTask, LinkedHashMap, HttpClient 메서드와 필드 remove, groupingBy, getCrc 상수 필드 MIN_VALUE, NEGATIVE_INFINITY 지역 변수 i, denom, houseNum 타입 매개변수 T,..

[Effective-Java] Chapter9 #67. 최적화는 신중히 하라

(맹목적인 어리석음을 포함해) 그 어떤 핑계보다 효율성이라는 이름 아래 행해진 컴퓨터 죄악이 더 많다(심지어 효율을 높이지도 못하면서). - 윌리엄 울프 (전체의 97% 정도인) 자그마한 효율성은 모두 잊자. 섣부른 최적화가 만악의 근원이다. 도널드 크루스 최적화를 할 때는 다음 두 규칙을 따르라. 첫 번째, 하지 마라. 두 번째, (전문가 한정) 아직 하지 마라. 다시 말해, 완전히 명백하고 최적화되지 않은 해법을 찾을 때까지는 하지 마라. - M. A. 잭슨 💡 빠른 프로그램보다는 좋은 프로그램을 작성하라 성능 때문에 견고한 구조를 희생하지 마라. 좋은 프로그램이지만 성능이 나오지 않는 것이라면 아키텍처 자체가 최적화의 길을 안내해줄 것이다. 좋은 프로그램은 정보 은닉 원칙을 따르므로 개별 구성요소의..