본문은 Effective Java를 읽고 간단하게 정리한 글입니다. 필요에 따라 생략/수정된 부분이 있을 수 있으며, 내용이 추후 변경될 수 있습니다. 선결론 readObject 메서드는 public 생성자처럼 조심스럽게 다루자 다음과 같이 작성하자 클래스 내 private 참조 필드는 참조 대상이 되는 객체를 방어적으로 복사해야 한다 방어적 복사 이후에는 불변식 검사를 수행하여 InvalidObjectException을 던져라 역직렬화 후 객체 그래프 전체의 유효성을 검사해야 한다면 ObjectInputValidation 인터페이스를 사용하라(이 책에서는 다루지 않는다) 직접적이든 간접적이든, 재정의할 수 있는 메서드는 호출하지 말자 readObject 메서드는 왜 또 다른 public 생성자라고 불리..
본문은 Effective Java를 읽고 간단하게 정리한 글입니다. 필요에 따라 생략/수정된 부분이 있을 수 있으며, 내용이 추후 변경될 수 있습니다. 선결론 스레드를 직접 관리하면서 작업을 수행하기보다는 이미 제공된 기술들을 적극적으로 활용하자 작업 큐를 손수 만들거나 스레드를 직접 다루는 일은 지양하자 실행자 프레임워크의 구성요소 자바는 비동기/병렬 처리를 위해 java.util.concurrent에서 실행자 프레임워크(Executor Framework)를 제공한다 실행자 프레임워크를 사용하면 스레드의 생성과 재사용을 쉽게 할 수 있기 때문에 Runnable 객체를 처리하는 데 유용하다 Executor 인터페이스 넘겨받은 Runnable 태스크를 실행하는 역할을 한다 public interface E..
본문은 Effective Java를 읽고 간단하게 정리한 글입니다. 필요에 따라 생략/수정된 부분이 있을 수 있으며, 내용이 추후 변경될 수 있습니다. 선결론 표준 예외를 적극적으로 재사용하라 자바에는 이미 재사용하기에 좋은 예외들이 충분히 많이 존재한다. 표준 예외 재사용의 장점 작성한 API가 다른 사람이 익히고 사용하기에 쉬워진다 이 API를 사용한 프로그램도 낯선 예외를 사용하지 않게 되어 가독성이 향상된다 예외 클래스 수가 적을 수록 메모리 사용량도 줄고 클래스를 적재하는 시간도 적게 걸린다(이미 JVM이 최적화가 너무 잘되어 있어 예외 클래스 몇개를 더 추가한다고 가시적인 성능저하가 일어나진 않을 것 같은데...) 재사용하기 좋은 예외들 1) IllegalArgumentException 호출자..
본문은 Effective Java를 읽고 간단하게 정리한 글입니다. 필요에 따라 생략/수정된 부분이 있을 수 있으며, 내용이 추후 변경될 수 있습니다. 선결론 검사 예외는 프로그램의 안정성을 높일 수 있지만, 남용한다면 API를 쓰기 어렵게 만들 수 있다 API 호출자가 예외 상황에서 복구할 방법이 없다면 비검사 예외를 던지자 복구가 가능하고 호출자가 그 처리를 해주길 바란다면 우선 옵셔널을 반환해도 될지 고민한 후, 옵셔널만으로 상황을 처리하기에 충분한 정보를 제공할 수 없을 때만 검사 예외를 던지자 검사 예외의 문제 호출하는 코드에서 catch 블록을 두어 처리하거나 throw를 통해 더 바깥으로 던져 문제를 전파해야만 한다 API 클라이언트측에 부담을 준다 throw를 통해 바깥으로 던질 경우 A..
본문은 Effective Java를 읽고 간단하게 정리한 글입니다. 필요에 따라 생략/수정된 부분이 있을 수 있으며, 내용이 추후 변경될 수 있습니다. 선결론 복구할 수 있는 상황이면 검사 예외를, 프로그래밍 오류라면 비검사 예외를 던지자 확실하지 않다면 비검사 예외를 던지자 검사 예외도 아니고 런타임 예외도 아닌 throwable은 정의하지 말자 검사 예외라면 복구에 필요한 정보를 알려주는 메서들들 제공하자 예외에 대한 기본 원칙 호출하는 쪽에서 복구하리라 여겨지는 상황이라면 검사 예외를 사용하라 API 설계자는 API 사용자에게 검사 예외를 던져주어 그 상황에서 회복해내라고 요구할 수 있다 프로그래밍 오류를 나타낼 떄는 런타임 예외를 사용하라 비검사 예외나 에러를 던졌다는 것은 복구가 불가능하거나 더..
