개발 기록

## 공유 중인 가변 데이터는 동기화해 사용하라 ### synchronized- 해당 메서드나 블록을 한번에 한 스레드씩 수행하도록 보장한다.- 동기화를 잘 하면 객체가 깨진 상태를 읽는 일이 없다. ### 동기화의 중요한 기능- 동기화는 일관성이 깨진 상태를 볼 수 없게 하는 것은 물론,- 동기화된 메서드나 블록에 들어간 스레드가 같은 락의 보호하에 수행된 모든 이전 수정의 최종 결과를 보게해준다. - 스레드가 만든 변화를 다른 스레드에서 확인하게 해준다. ### 원자적 데이터- 언어 명세상 long 과 double 외의 변수를 읽고 쓰는 동작은 원자적이다.- 여러 스레드가 같은 변수를 동기화 없이 수정하는 중이라도, 항상 어떤 스레드가 정상적으로 저장한 값을 온전히 읽어옴을 보장.- int, boo..

## 예외를 무시하지 말라 ### 예외를 명시하는 까닭- 메서드를 사용할때 적절한 조치를 취해달라고 말하는 것.// catch 블록을 비워두면 예외가 무시된다. 아주 의심스러운 코드다!try {} catch (SomeException e) {} - catch 블록을 비워두면 예외가 존재할 이유가 없어진다. ### 예외를 무시해야할때- ex) Fileinputstream을 닫을 때(입력 전용 스트림이므로) 파일의 상태를 변경하지 않았으니 복구할 것이 없으며, (스트림을 닫는다는 건) 필요한 정보는 이미 다 읽었다는 뜻이니 남은 작업을 중단할 이유도 없다. - 예외를 무시하기로 했다면 catch 블록 안에 그렇게 결정한 이유를 주석으로 남기고 예외 변수의 이름도 ignored로 바꿔놓도록 하자. Future..

## 메서드가 던지는 모든 예외를 문서화하라 메서드가 던지는 예외는 그 메서드를 올바로 사용하는 데 아주 중요한 정보다.따라서 각 메서드가 던지는 예외 하나하나를 문서화하는 데 충분한 시간을 쏟아야 한다 ### 검사 예외는 항상 따로따로 선언하고, 각 예외가 발생하는 상황을 자바독의 @throws 태그를 사용하여 정확히 문서화하자.공통 상위 클래스 하나로 뭉뚱그려 선언하는 일은 삼가자.극단적인 예로 메서드가 Exception이나 Throwable을 던진다고 선언해서는 안 된다.메서드 사용자에게 각 예외에 대처할 수 있는 힌트를 주지 못할뿐더러, 같은 맥락에서 발생할 여지가 있는 다른 예외들까지삼켜버릴 수 있어 API 사용성을 크게 떨어뜨린다. ### 자바 언어가 요구하는 것은 아니지만 비검사 예외도 검사..

## 표준 예외를 사용하라 ### 표준 예외를 사용해야 하는 이유표준이기 때문에 다른 개발자가 내 코드에서 예외의 의미를 이해하기 쉬워진다.클래스를 적게 만들어 성능상의 이득도 있다.자바 라이브러리에서 충분한 수의 예외를 제공해줘서 일반적인 경우 표준 예외로 전부 처리가 가능하다.직렬화에도 용이하다.### 표준 예외 중 자주 쓰이는 것들IllegalArgumentException이름 그대로 잘못된 인수를 넘겼을 때 던져주는 예외이다.ex) 사람의 나이 설정에 음수를 넘겼을 때관례적으로 null은 NullPointerException을 이용한다.IllegalStateException객체의 상태가 메서드 수행에 적합하지 않을 때객체 초기화 자체가 제대로 되지 않은채로 메서드를 수행한다면 IllegalStat..

## 필요없는 검사 예외 사용은 피하라 ### 검사 예외의 불편함 검사 예외를 싫어하는 개발자가 많지만 제대로 활용하면 API와 프로그램의 질을 높일 수 있다.반면 사용이 과해지면 불편하기만 할 수도 있다. (검사 예외를 던지는 메서드는 스트림 안에서 직접 사용할 수 없기 때문에 자바 8부터는 부담이 더욱 커졌다) 검사 예외가 프로그래머에게 지우는 부담은 메서드가 단 하나의 검사 예외만 던질 때가 특히 크다.API 안에 검사 예외가 여러개 있을 때나, 하나만 있을 때나 어차피 try catch로 묶거나 throws로 던져줘야 하는건 똑같다.그리고 이처럼 검사 예외에 대한 책임을 지게 되면 해당 메서드를 스트림에서 직접 사용할 수 없다. ### 검사 예외 회피 방법 :: 1. 비검사 예외 API를 제대..

## 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라 자바에는 문제 상황을 알리는 타입으로 검사 예외, 런타임 예외, 에러, 이렇게 세가지를 제공한다.하지만 언제 무엇을 사용해야 하는지 헷갈려 하는 프로그래머들이 종종 있다.이럴 때 참고하면 좋은 지침들을 알아보자. ###검사 예외 (Checked Exception)호출하는 쪽에서 복구하리라 여기지는 상황검사 예외를 던지면 호출자가 그 예외를 catch로 잡아 처리하거나 더 바깥으로 전파하도록 강제하게 된다.따라서 메서드 선언에 포함된 검사 예외 각각은 그 메서드를 호출했을 때 발생할 수 있는 유력한 결과임을 API 사용자에게 알려주는 것이다.API 설계자는 API 사용자에게 검사 예외를 던져주어 그 상황에서 회복해내라고..

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

## 예외는 진짜 예외 상황에만 사용하라 ### 예외가 아닌 상황에 예외를 사용했을 때try { int i = 0; while(true) { range[i++].climb(); }} catch (ArrayIndexOutOfBoundsException e) {}위 코드의 의도는 일반적인 반복문에서 반복문도 매 반복마다 배열의 경계를 넘는지 검사하고, JVM도 배열에 접근할 때마다 경계를 넘는지 검사하는데, 그 중복을 없애서 성능 최적화를 하려던 의도이다.### 잘못된 이유JVM 구현자 입장에서는 위 같은 코드가 빠르게 돌아갈지에 대해서는 전혀 고려하지 않을 것이다.예외는 예외를 처리하는데 쓰라는 구현자의 의도와 다르게 코드를 작성했기 때문이다.예외를 로직에 이용하면 안된다.코드를 try-catc..