IT/Programming

<Effective Java> RULE 60 표준 예외를 사용하라

프로그래밍 전문가는 코드 재사용을 위해 노력할 뿐만 아니라 높은 수준으로 코드를 재사용한다. 이미 있는 예외를 사용하는 좋은 장점 · 배우기 쉽고 사용하기 편리한 API를 만들기 쉽다. · 구현된 API는 가독성이 높아진다. 가장 많이 사용되는 예외 · IllegalArgumentException : 잘못된 인자를 던졌을 시 · IllegalStateException : 현재 객체 상태로는 호출할 수 없는 메서드를 호출 했을 때 · NullPointerException : null값을 받으면 안되는 인자에 null값이 전달 되었을 때 · ConcurrentModificationException : 하나의 스레드만 사용하도록 설계된 객체나 외부적인 동기화 수단과 함께 이용되어야 하는 객체를 여러 스레드가 ..

2023. 4. 26. 13:31

IT/Programming

<Effective Java> RULE 61 추상화 수준에 맞는 예외를 던져라

상위 계층에서는 하위 계층에서 발생하는 예외를 반드시 받아서 상위 계층 추상화 수준에 맞는 예외로 바꿔서 던져야 한다. (예외 변환, exception translation) // 예외 변환 try{ // 낮은 수준 추상화 계층 이용 ... } catch(LowerLevelException e){ throw new HigherLevelException(...); } // 예외 연결 지원 생성자를 갖춘 예외 class HigherLevelException extends Exception{ HigherLevelException(Throwable cause){ super(cause); } } 대부분 표준 예외는 예외 연결 지원 생성자를 구비하고 있다. 해당 생성자가 없다면 Throwable.initCause를..

2023. 4. 26. 13:30

IT/Programming

<Effective Java> RULE 62 메서드에서 던져지는 모든 예외에 대해 문서를 남겨라

· 점검지정 예외는 독립적으로 선언하고, 해당 예외가 발생하는 상황은 javadoc @throws 태그를 사용해서 정확하게 밝혀라. · javadoc @throws 태그를 사용해서 메서드에서 발생한 가능한 모든 무점검 예외에 대한 문서를 남겨라, 하지만 메서드 선언부의 throws뒤에 무점검 예외를 나열하진 마라. · 동일한 예외를 던지는 메서드가 많다면 메서드마다 문서를 만드는 대신, 해당 예외에 대한 문서는 클래스의 문서 주석에 남겨도 된다. ㄴ ex) 이 클래스에 있는 모든 메서드는 인자로 null이 전달되면 NullPointException을 발생시킨다. · 점검 지정 예외 뿐만 아니라, 무점검 예외에도 문서를 만들어라. · 일반 메서드 뿐만 아니라, abstract메서드에도 문서를 만들어라. ·..

2023. 4. 26. 13:29

IT/Programming

<Effective Java> RULE 63 어떤 오류인지를 드러내는 상세한 메세지를 담으라.

무점검 예외 때문에 프로그램이 죽으면, 시스템은 해당 예외에 스택 추적 정보를 출력한다. 따라서 toString 메서드가 반환하는 문자열에 오류 원인에 관계된 정보를 최대한 많이 담는 것이 중요하다. 오류 정보를 포착해 내기 위해서는, 오류의 상세 메시지에 “예외에 관계된” 모든 인자와 필드의 값을 포함시켜야 한다. ex) IndexOutOfBoundsException의 예외 메세지에는 첨자의 하한과 상한 그리고 그 범위를 벗어난 첨자값이 포함되어햐 한다. public IndexOutOfBoundsException(int lowerBound, int upperBound, int index){ // 오류를 포착하는 상세 메세지 생성 super("Lower bound : " + lowerBound + ", ..

2023. 4. 26. 13:29

IT/Programming

<Effective Java> RULE 64 실패 원자성 달성을 위해 노력하라

예외를 던지고 난 뒤에도 객체의 상태가 잘 정의된, 사용 가능한 상태로 남아 있으면 좋다. 일반적으로, 메서드 호출이 정상적으로 처리되지 못한 객체의 상태는 메서드 호출 전 상태와 동일 해야 한다. 이 속성을 만족하는 메서드는 실패 원자성을 갖추었다고 한다. 실패원자성을 달성하는 방법 · 변경 불가능 객체로 설계하는 것. · 실제 연산하기 전 인자의 유효성을 검사하는 방법 · 연산 수행 도중 발생하는 오류를 가로채는 복구 코드를 작성하는 것 · 객체의 임시 복사본 상에서 필요한 연산을 수행하고 연산이 끝난 다음에 임시 복사본의 내용으로 객체 상태를 바꾸는 것이다. 메서드 명세에 포함된 예외가 발생하더라도 객체 상태는 메서드 호출 이전과 동이랗게 유지되어야 한다. 이 규칙을 지키지 못할 경우 객체 상태가 ..

2023. 4. 26. 13:28

IT/Programming

<Effective Java> RULE 65 예외를 무시하지 마라

// catch 블록을 비워 놓으면 예외는 무시된다. try{ ... } catch(SomeException e) { } 빈 catch블록은 반드시 해당 예외적 상황에 대해 처리하라고 강제하기 위한 목적으로 작성된다. 즉, 예외를 무시하는 것은 경고를 무시하는것과 같다. 적어도 catch블록 안에는 예외를 무시해도 괜찮은 이유라도 주석을 남겨 두어야 한다. 위를 무시하게 되면 어느 순간, 오류와는 아무 상관 없는 지점에서 불시에 죽어버릴 수 있다.

2023. 4. 26. 13:28