조이리

실패 원자적 일반화 해서 말하자면 호출된 메서드가 실패 하더라도 해당 객체는 메서드 호출 전 상태를 유지해야 한다. 메서드를 원자적으로 만드는 방법 불변 객체 가장 간단한 방법은 불변객체로 설계하는 방법이다. 메서드가 실패하면 새로운 객체가 만들어지지 않을 수 있으나, 기존 객체가 불안정한 상태에 빠질 일은 결코 없다. 불변객체의 상태는 생성 시점에 고정되어 절대 변하지 않기 때문이다. 매개변수 유효성 검사 public Object pop() { if(size == 0){ throw new EmptyStackException(); } Object result = elements[--size]; elements[size] = null // 다쓴 참조 해제 return result; } 임시 복사본 사용 객..

스택 추적 예외를 잡지 못해 프로그램이 실패하면 자바 시스템은 그 예외의 스택 추적(stack trace) 정보를 자동으로 출력한다. 예외 객체의 toString 메서드를 호출해 얻는 문자열이다 예외의 클래스 이름 뒤에 상세 메시지가 붙는 형태이다 실패 순간을 포착하려면 발생한 예외에 관여된 모든 매개변수와 필드의 값을 실패 메시지에 담아야 된다. public IndexOutOfBoundsException(int lowerBound, int upperBound, int index) { // 실패률 포착하는 상세 메시지를 생성한다. super(String.format( "최솟값: %d , 최댓값: %d, 인덱스: %d", lowerBound, upperBound, index)); // 프로그램에서 이용할 ..

검사 예외 검사 예외는 항상 따로따로 선언하고, 각 예외가 발생하는 상황을 javadoc의 @throw 태그를 사용하여 정확히 문서화 하자 공통 상위 클래스 하나로 뭉뚱그려 선언하는 일은 삼가자 비검사 예외 비검사 예외도 검사 예외처럼 정성껏 문서화 해두면 좋다. 비검사 예외는 일반적으로 프로그래밍 오류를 뜻하는데, 자신이 일으킬 수 있는 오류들을 알려주면 사용하는 입장에서 도움이 된다. 메서드가 던질 수 있는 예외를 각각 @throws 태그로 문서화하되, 비검사 예외는 메서드 선언의 throws 목록에 넣지 말자 검사냐 비검사냐에 따라 사용자가 해야 할 일이 달라지므로 둘을 구분해주는것은 좋다. 현실적으로 불가능할때 비검사 예외는 문서화하기 불가능할 때도 있다. 예컨대 다른 사람이 작성한 클래스를 사용..

문제상황 수행하려는 일과 관련 없어 보이는 예외가 튀어나오면 당황스럽다 메서드가 저수준 예외를 처리하지 않고 바깥으로 전파해버릴 때 종종 일어나는 일이다 해결방법 예외번역(Exception translation) 상위 계층에서는 저수준 예외를 잡아 자신의 추상화 수준에 맞는 예외로 바꿔 던져야 한다 public E get(int index) { ListIterator i = listIterator(index); try { return i.next(); } catch (NoSuchElementException e) { throw new IndexOutOfBoundsException("인덱스: " + index); } } 예외 연쇄(Exception chaning) 예외를 번역 할때 저수준 예외가 디버깅에 ..

표준 예외 재사용의 장점 사용하기 쉽고 익숙하다 읽기 쉽다 메모리 사용량도 줄고 클래스를 적재하는 시간도 적다 대표적인 예외 IllegalArgumentException 가장 많이 재사용되는 예외로, 호출자가 인수로 부적절한 값을 넘길 때 던지는 예외다. (ex. 반복 횟수를 지정하는 매개변수에 음수가 할당될 때) IllegalStateException 이 예외는 대상 객체의 상태가 호출된 메서드를 수행하기에 적합하지 않을 때 주로 던진다. 제대로 초기화되지 않은 객체를 사용하려 할 때 던질 수 있다. NullPointerException 메서드가 던지는 모든 예외를 잘못된 인수나 상태라고 포괄적으로 생각할 수도 있어, IllegalArgument라고 볼 수도 있겠으나, 그 중 특수한 일부는 따로 구분해..

검사 예외의 불편 검사 예외를 싫어하는 개발자가 많지만 제대로 활용하면 API와 프로그램의 질을 높일 수 있다. 반면 사용이 과해지면 불편하기만 할 수도 있다. 검사 예외가 단 하나뿐이라면 오직 그 예외 때문에 API 사용자는 try 블록을 추가해야 하고 스트림에서 직접 사용하지 못하게 된다. 그러니 이런 상황이라면 검사 예외를 안 던지는 방법이 없는지 고민해볼 가치가 있다. 검사 예외 회피 방법 비검사 예외 API를 제대로 사용해도 발생할 수 있는 예외이거나, 프로그래머가 의미 있는 조치를 취할 수 있는 경우라면 이 정도 부담쯤은 받아들일 수 있을 것이다. 하지만 이 경우들이 아니라면, 비검사 예외를 사용하는 것이 좋다. Optional 검사 예외를 회피하는 두 번째 방법은 적절한 결과 타입을 담은 옵..

검사 예외와 런타임 예외 자바는 문제 상황을 알리는 타입(Throwable)으로 검사 예외, 런타임 예외, 에러 이렇게 세 가지를 제공한다. 하지만, 해당 타입을 언제 무엇을 사용해야하는 지 헷갈리는 경우가 있다. 참고 지침 호출하는 쪽에서 복구하리라 여겨지는 상황이라면 검사 예외를 사용하라. 검사 예외를 던지면 호출자가 그 예외를 catch로 잡아 처리하거나 더 바깥으로 전파하도록 강제하게 된다. 따라서, 메소드 선언에 포함된 검사 예외 각각은 그 메소드를 호출했을 때 발생할 수 있는 유력한 결과임을 API 사용자에게 알려주는 것이다. 비검사 throwable은 두 가지로, 런타임 예외와 에러이다. 이 둘은 프로그램에서 잡을 필요가 없거나 혹은 통상적으로 잡지 말아야 한다. 프로그램에서 비검사 예외나 ..

예외는 오직 예외 상황에서만 써야한다. 절대 일상적인 제어 흐름용으로 사용해선 안 된다. try { int i = 0; while(true) range[i++].climb(); } catch (ArraylndexOutOfBoundsException e) { } //표준적인 관용구 for (Mountain m : range) m.climb(); 잘못된 추론 예외를 통한 명확한 검사가 빠를 것이다. 코드를 try-catch 블록 안에 넣으면 JVM이 적용할 수 있는 최적화가 제한된다. JVM은 배열에 접근할 때마다 경계를 넘지않는지 매번 검사하므로. 이 부분을 제한한다는 추론으로 보인다. 배열을 순회하는 표준 관용구 는 JVM이 알아서 최적화해 중복 검사를 진행하지 않는다. 여기서 말한 중복검사는 JVM에서..

스레드 스케줄러 여러 스레드가 실행중이면 운영체제의 스레드 스케줄러가 어떤 스레드를 얼마나 오래 실행할지 정한다. 스레드 스케줄링 정책은 OS다를 수 있기 때문에, 프로그램은 이 정책에 좌지우지 되어서는 안된다. 특징 이식성 좋은 프로그램은 실행 가능한 스레드의 평균적인 수를 프로세서 수보다 지나치게 많아지지 않도록 하는 것이다. 스레드 스케줄러가 고민할 거리가 줄어든다. 실행 가능한 스레드의 수는 전체 스레드 수와 다르다. 실행 준비가 된 스레드들은 맡은 작업을 완료할 때까지 계속 실행되도록 만든다. 실행 가능한 스레드 수를 적게 유지하는 방법은 각 스레드가 작업을 완료한 후 다음 일거리가 생길 때까지 대기하도록 하는 것이다. 당장 처리해야 할 작업이 없다면 실행돼서는 안 된다. 스레드 풀을 적절히 설..

지연초기화 필드의 초기화 시점을 그 값이 처음 필요할때까지 늦추는 기법이다 그래서 값이 전혀 쓰이지 않으면 초기화도 일어나지 않는다 대부분의 상황에서 일반적인 초기화가 지연 초기화보다 낫다 지연 초기화가 초기화 순환성(initialization circularity)을 깨뜨릴 것 같으면 synchronized를 단 접근자를 사용 private FieldType field; private synchronized FieldType getFieldO { if (field = null) field = computeFieldValue〇; return field; } 성능 때문에 정적 필드를 지연 초기화해야 한다면 지연 초기화 홀더 클래스 (lazy initialization holder class) 관용구를 사용..