메소드가 여러 유형의 확인 된 예외를 처리하지 않아야하는 이유는 무엇입니까?

SonarQube를 사용하여 Java 코드를 분석하고이 규칙 (중요하게 설정 됨)이 있습니다.

공개 메소드는 최대 하나의 확인 된 예외를 처리해야합니다.

확인 된 예외를 사용하면 메소드 호출자가 오류를 전파하거나 처리하여 오류를 처리해야합니다. 이것은 예외를 메소드 API의 일부로 만듭니다.

호출자의 복잡성을 합리적으로 유지하기 위해 메소드는 여러 종류의 확인 된 예외를 발생시키지 않아야합니다. "

Sonar의 또 다른 비트는 다음과 같습니다.

공개 메소드는 최대 하나의 확인 된 예외를 처리해야합니다.

확인 된 예외를 사용하면 메소드 호출자가 오류를 전파하거나 처리하여 오류를 처리해야합니다. 이것은 예외를 메소드 API의 일부로 만듭니다.

호출자의 복잡성을 합리적으로 유지하기 위해 메소드는 여러 종류의 확인 된 예외를 발생시키지 않아야합니다.

다음 코드 :

public void delete() throws IOException, SQLException {      // Non-Compliant
  /* ... */
}

리팩토링해야합니다 :

public void delete() throws SomeApplicationLevelException {  // Compliant
    /* ... */
}

재정의 메소드는이 규칙에 의해 점검되지 않으며 점검 된 여러 예외를 처리 할 수 ​​있습니다.

예외 처리에 대한 내 독서 에서이 규칙 / 권장 사항을 결코 읽지 않았으며 주제에 대한 표준, 토론 등을 찾으려고 시도했습니다. 내가 찾은 유일한 것은 CodeRach의 것입니다. 메소드는 얼마나 많은 예외를 던져야합니까?

이것이 잘 받아 들여지는 표준입니까?

제공된 코드가있는 상황을 고려하십시오.

public void delete() throws IOException, SQLException {      // Non-Compliant
  /* ... */
}

여기서의 위험은 호출하기 위해 작성한 코드 delete()가 다음과 같습니다.

try {
  foo.delete()
} catch (Exception e) {
  /* ... */
}

이것도 나쁘다. 그리고 기본 Exception 클래스를 잡는 플래그를 지정하는 또 다른 규칙이 있습니다.

핵심은 다른 곳에서 잘못된 코드를 작성하도록하는 코드를 작성하지 않는 것입니다.

당신이 겪는 규칙은 다소 일반적인 규칙입니다. Checkstyle 은 디자인 규칙에 다음과 같이 있습니다.

ThrowsCount

명령문을 지정된 개수 (기본적으로 1)로 제한합니다.

이론적 근거 : 예외는 메소드 인터페이스의 일부이다. 너무 많은 다른 근본 예외를 처리하는 메소드를 선언하면 예외 처리가 번거로워지고 catch (Exception ex)와 같은 코드 작성과 같은 프로그래밍 방식이 잘못됩니다. 이 검사를 통해 개발자는 예외를 계층 구조에 넣어 가장 간단한 경우 호출자가 한 가지 유형의 예외 만 검사해야하지만 필요한 경우 하위 클래스를 구체적으로 잡을 수 있습니다.

이것은 문제와 문제가 무엇인지, 왜하지 말아야 하는지를 정확하게 설명합니다. 많은 정적 분석 도구가 식별하고 플래그를 지정하는 것이 널리 인정되는 표준입니다.

당신이 반면 수 있습니다 언어 설계에 따라 작업을 수행하고있을 수 는 옳은 일 때 배, 당신이보고 즉시 가야한다 무언가이다 "음, 내가 왜이 일을하고있다?" 모든 사람이 결코 징계 할 수 없을 정도로 훈련 된 내부 코드에는 허용 될 수 catch (Exception e) {}있지만, 특히 내부 상황에서 사람들이 모퉁이를 깎는 것을 보지 못한 경우가 많습니다.

수업을 이용하는 사람들이 나쁜 코드를 작성하도록하지 마십시오.

나는 이것의 중요성은 자바 SE 7 줄어들 단일 catch 문이 여러 예외를 잡을 수 나중에 있기 때문에 (것을 지적해야 여러 예외 유형 잡기 및 확인 향상된 유형과 예외 Rethrowing 오라클을).

Java 6 및 이전 버전에서는 다음과 같은 코드가 있습니다.

public void delete() throws IOException, SQLException {
  /* ... */
}

과

try {
  foo.delete()
} catch (IOException ex) {
     logger.log(ex);
     throw ex;
} catch (SQLException ex) {
     logger.log(ex);
     throw ex;
}

또는

try {
    foo.delete()
} catch (Exception ex) {
    logger.log(ex);
    throw ex;
}

Java 6에서 이러한 옵션 중 어느 것도 이상적이지 않습니다. 첫 번째 방법은 위반 DRY . 여러 예외가 같은 일을 반복해서 반복합니다-각 예외마다 한 번씩. 예외를 기록하고 다시 throw 하시겠습니까? 승인. 각 예외에 대해 동일한 코드 줄.

두 번째 옵션은 몇 가지 이유로 더 나쁩니다. 첫째, 그것은 당신이 모든 예외를 잡고 있음을 의미합니다. 널 포인터가 거기서 잡히지 않아야합니다. 또한, 당신은 코드를 다시 사용하는 사람들이 강제 로 스택을 더 혼란스럽게 만드는 Exception메소드 서명이 될 것을 의미 하는를 다시 던지고 있습니다 .deleteSomething() throws Exceptioncatch(Exception e)

자바 7, 이것은 아니다 으로 대신 할 수 있기 때문에 중요합니다 :

catch (IOException|SQLException ex) {
    logger.log(ex);
    throw ex;
}

또한, 하나의 경우 검사 유형 않는 예외의 유형을 잡기가 발생되고 :

public void rethrowException(String exceptionName)
throws IOException, SQLException {
    try {
        foo.delete();
    } catch (Exception e) {
        throw e;
    }
}

그 인식 유형 검사는 e수 만 종류의 수 IOException또는 SQLException. 나는 여전히이 스타일의 사용에 대해 지나치게 열성적 인 것은 아니지만 Java 6에서와 같이 나쁜 코드를 일으키지 않습니다 (메소드 서명이 예외를 확장하는 수퍼 클래스가되도록 강요 할 것입니다).

이러한 모든 변경에도 불구하고 많은 정적 분석 도구 (Sonar, PMD, Checkstyle)는 여전히 Java 6 스타일 안내서를 시행하고 있습니다. 나쁜 것이 아닙니다. 나는 이것들이 여전히 시행 될 것이라는 경고에 동의하는 경향이 있지만, 당신은 당신의 팀이 우선 순위를 정하는 방법에 따라 우선 순위를 주 또는 부로 변경할 수 있습니다.

예외가 선택 또는 선택 취소해야하는 경우 ... 그의 문제입니다 g의 r에 전자 t의 논쟁 하나가 쉽게 인수의 각면을 차지 수많은 블로그 게시물을 찾을 수 있습니다. 그러나 확인 된 예외로 작업하는 경우 적어도 Java 6에서 여러 유형을 던지지 않아야합니다.

이상적으로 한 가지 유형의 예외 만 발생시키려는 이유는 단일 책임 및 종속성 반전 원칙을 위반할 가능성이 있기 때문 입니다. 예제를 사용하여 시연 해 봅시다.

지속성에서 데이터를 가져 오는 방법이 있고 지속성이 파일 세트라고 가정 해 봅시다. 파일을 다루기 때문에 다음과 같이 할 수 있습니다 FileNotFoundException.

public String getData(int id) throws FileNotFoundException

이제 요구 사항이 변경되었으며 데이터베이스에서 데이터가 제공됩니다. FileNotFoundException(파일을 다루지 않기 때문에) 대신에 SQLException:

public String getData(int id) throws SQLException

이제 메소드를 사용하는 모든 코드를 살펴보고 확인해야 할 예외를 변경해야합니다. 그렇지 않으면 코드가 컴파일되지 않습니다. 우리의 방법이 광범위하고 광범위하게 호출된다면, 그것은 다른 사람들을 변화 시키거나 바꾸는 데 많은 도움이 될 수 있습니다. 많은 시간이 걸리고 사람들은 행복하지 않을 것입니다.

의존성 반전은 캡슐화하려고하는 내부 구현 세부 사항을 노출하기 때문에 이러한 예외 중 하나를 던져서는 안된다고 말합니다. 호출 코드는 레코드를 검색 할 수 있는지 실제로 걱정할 때 사용하는 지속성 유형을 알아야합니다. 대신 API를 통해 노출하는 것과 동일한 추상화 수준에서 오류를 전달하는 예외를 처리해야합니다.

public String getData(int id) throws InvalidRecordException

이제 내부 구현을 변경하면 해당 예외를 랩으로 감싸서 InvalidRecordException전달할 수 있습니다 (또는 랩핑하지 않고 그냥 새 던지기 InvalidRecordException). 외부 코드는 어떤 유형의 지속성이 사용되는지 알거나 신경 쓰지 않습니다. 모두 캡슐화되어 있습니다.

단일 책임에 관해서는 관련되지 않은 여러 예외를 발생시키는 코드에 대해 생각해야합니다. 다음과 같은 방법이 있다고 가정 해 봅시다.

public Record parseFile(String filename) throws IOException, ParseException

이 방법에 대해 무엇을 말할 수 있습니까? 우리는이 파일을 열 서명에서 알 수 및 그것을 구문 분석합니다. 메소드 설명에서 "and"또는 "or"와 같은 연결을 볼 때, 둘 이상의 작업을 수행한다는 것을 알고 있습니다. 그것은 하나 이상의 책임이 있습니다. 하나 이상의 책임이있는 방법은 책임이 변경 될 경우 변경 될 수 있으므로 관리하기가 어렵습니다. 대신, 우리는 단일 책임을 갖도록 메소드를 분리해야합니다.

public String readFile(String filename) throws IOException
public Record parse(String data) throws ParseException

데이터를 파싱하는 책임에서 파일을 읽는 책임을 추출했습니다. 이것의 한 가지 부작용은 이제 모든 인 메모리, 파일, 네트워크 등 모든 소스에서 파싱 데이터로 문자열 데이터를 전달할 수 있다는 것입니다. parse디스크에 파일이 필요하지 않기 때문에 더 쉽게 테스트 할 수도 있습니다. 에 대한 테스트를 실행합니다.

때로는 메소드에서 예외가 발생할 수있는 예외가 두 개 이상 있지만, SRP와 DIP를 고수하면 이러한 상황이 발생하는 시간이 더 드 become니다.

Java를 잠시 재생할 때이 문제를 조금이라도 해결하는 것을 기억하지만, 질문을 읽을 때까지 확인 된 것과 확인되지 않은 것의 구별을 실제로 의식하지 않았습니다. Google 에서이 기사를 매우 빨리 발견했으며 명백한 논쟁 중 일부에 해당합니다.

http://tutorials.jenkov.com/java-exception-handling/checked-or-unchecked-exceptions.html

즉,이 사람이 확인 된 예외로 언급 한 문제 중 하나는 throws메소드 선언의 절에 여러 가지 확인 된 예외를 계속 추가하면 (Java에서 처음부터 개인적으로 실행했습니다) 더 높은 수준의 메소드로 이동할 때 더 많은 상용구 코드를 넣어야하지만 더 많은 예외 유형을 더 낮은 레벨의 메소드에 도입하려고 할 때 더 큰 혼란을 일으키고 호환성을 손상시킵니다. 확인 된 예외 유형을 하위 레벨 메소드에 추가하는 경우 코드를 다시 실행하고 다른 여러 메소드 선언도 조정해야합니다.

이 기사에서 언급 한 완화의 한 가지 점은 저자가 개인적으로 좋아하지 않았기 때문에 기본 클래스 예외를 작성하고 throws절만 사용하도록 절을 제한 한 다음 내부적으로 하위 클래스를 올리는 것이 었습니다. 이렇게하면 모든 코드를 다시 실행하지 않고도 새로운 확인 된 예외 유형을 만들 수 있습니다.

이 기사의 저자는 이것을 좋아하지는 않았지만 개인적인 경험 (특히 모든 하위 클래스가 무엇인지 찾을 수있는 경우)에서 완벽하게 이해가되며, 그 이유는 당신에게 주어진 조언이 하나의 확인 된 예외 유형에 모든 것을 제한하십시오. 또한 언급 한 조언은 실제로 비공개 메소드에서 여러 가지 확인 된 예외 유형을 허용하므로 이것이 동기 (또는 그 밖의 경우)라면 완벽하게 이해됩니다. 어쨌든 개인적인 방법이거나 비슷한 것이면 작은 것을 바꿀 때 코드베이스의 절반을 넘지 않을 것입니다.

이 표준이 받아 들여질 표준인지는 거의 묻지 않았지만, 당신이 언급 한 연구, 합리적으로 생각한 기사, 그리고 개인적인 프로그래밍 경험으로 말하면 분명히 어떤 식 으로든 두드러지지 않는 것 같습니다.

여러 가지 확인해야 할 예외가 발생하면 합리적인 여러 조치가있을 때 의미가 있습니다.

예를 들어 방법이 있다고 가정 해 봅시다.

public void doSomething(Credentials cred, Work work) 
    throws CredentialsRequiredException, TryAgainLaterException{...}

이것은 pne 예외 규칙을 위반하지만 의미가 있습니다.

불행히도, 평소에 일어나는 일은 다음과 같은 방법입니다.

void doSomething() 
    throws IOException, JAXBException,SQLException,MyException {...}

여기에서는 호출자가 예외 유형에 따라 특정 작업을 수행 할 가능성이 거의 없습니다. 따라서 만약 우리가이 방법들이 때때로 잘못 될 수 있다는 것을 깨닫고 자한다면, SomethingMightGoWrongException을 던지는 것은 아주 훌륭합니다.

따라서 최대 하나의 확인 된 예외가 규칙입니다.

그러나 프로젝트에서 의미있는 전체 검사 예외가 여러 개있는 디자인을 사용하는 경우이 규칙이 적용되지 않습니다.

참고 : 실제로 거의 모든 곳에서 문제가 발생할 수 있으므로? RuntimeException을 확장하지만 "우리 모두 실수를 저지 릅니다"와 "이것은 외부 시스템과 대화하며 때때로 다운되어 처리합니다"사이에는 차이가 있습니다.