면접 관: 자바 의 이상 을 어떻게 처리 하 세 요?

1. finally 블록 에서 자원 을 정리 하거나 try - with - resource 문 구 를 사용 합 니 다.
InputStream 과 같은 사용 후 닫 아야 할 자원 을 사용 할 때 흔히 볼 수 있 는 오 류 는 try 블록 의 마지막 에 자원 을 닫 는 것 입 니 다.

public void doNotCloseResourceInTry() {
    FileInputStream inputStream = null;
    try {
        File file = new File("./tmp.txt");
        inputStream = new FileInputStream(file);
        // use the inputStream to read a file
        // do NOT do this
        inputStream.close();
    } catch (FileNotFoundException e) {
        log.error(e);
    } catch (IOException e) {
        log.error(e);
    }
}

문 제 는 이상 이 없 을 때 만 이 코드 가 정상적으로 작 동 할 수 있다 는 점 이다.try 코드 블록 내 코드 가 정상적으로 실행 되 고 자원 이 정상적으로 닫 힐 수 있 습 니 다.그러나 try 코드 블록 을 사용 하 는 데 는 이유 가 있 습 니 다. 보통 하나 이상 을 던 질 수 있 는 방법 을 호출 합 니 다. 그리고 자신 도 이상 을 던 질 수 있 습 니 다. 이것 은 코드 가 try 코드 블록 의 마지막 부분 까지 실행 되 지 않 을 수 있 음 을 의미 합 니 다.결국 자원 을 닫 지 않 았 다 는 것 이다.
따라서 청소 작업 의 코드 를 finally 에 넣 거나 try - with - resource 기능 을 사용 해 야 합 니 다.
1.1 finally 코드 블록 사용
앞의 몇 줄 try 코드 블록 과 달리 finally 코드 블록 은 항상 실 행 됩 니 다.try 코드 블록 이 성공 적 으로 실 행 된 후에 도 catch 코드 블록 에서 이상 을 처리 한 후에 실 행 됩 니 다.따라서 열 린 모든 자원 을 정리 할 수 있 도록 확보 할 수 있다.

public void closeResourceInFinally() {
    FileInputStream inputStream = null;
    try {
        File file = new File("./tmp.txt");
        inputStream = new FileInputStream(file);
        // use the inputStream to read a file
    } catch (FileNotFoundException e) {
        log.error(e);
    } finally {
        if (inputStream != null) {
            try {
                inputStream.close();
            } catch (IOException e) {
                log.error(e);
            }
        }
    }
}

1.2 자바 7 의 try - with - resource 문법
만약 당신 의 자원 이 AutoCloseable 인 터 페 이 스 를 실현 한다 면, 당신 은 이 문법 을 사용 할 수 있 습 니 다.대부분의 자바 표준 자원 이 이 인 터 페 이 스 를 계승 했다.try 자구 에서 자원 을 열 면 자원 은 try 코드 블록 이 실 행 된 후 또는 이상 처리 후 자동 으로 닫 힙 니 다.

public void automaticallyCloseResource() {
    File file = new File("./tmp.txt");
    try (FileInputStream inputStream = new FileInputStream(file);) {
        // use the inputStream to read a file
    } catch (FileNotFoundException e) {
        log.error(e);
    } catch (IOException e) {
        log.error(e);
    }
}

2. 우선 명확 한 이상
당신 이 던 진 이상 은 명확 할 수록 좋 습 니 다. 당신 의 동료 나 몇 달 후의 당신 은 당신 의 방법 을 사용 하고 이상 을 처리 할 것 이라는 것 을 영원히 기억 하 세 요.
그래서 그들 에 게 가능 한 한 많은 정 보 를 제공 할 것 을 보증 해 야 한다.이렇게 하면 당신 의 API 가 더욱 쉽게 이해 된다.당신 의 방법의 호출 자 는 이상 을 더욱 잘 처리 하고 추가 검 사 를 피 할 수 있 습 니 다.
따라서, 항상 당신 에 게 가장 적합 한 이상 한 사건 의 종 류 를 찾 으 려 고 시도 합 니 다. 예 를 들 어, NumberFormat Exception 을 던 져 서 IllegalArgument Exception 을 교체 합 니 다.명확 하지 않 은 이상 을 던 지지 않도록 해라.

public void doNotDoThis() throws Exception {
    ...
}
public void doThis() throws NumberFormatException {
    ...
}

3. 이상 에 대한 문서 설명
방법 상 이상 을 던 졌 다 고 밝 힐 때 도 문서 설명 이 필요 하 다.호출 자 에 게 가능 한 한 많은 정 보 를 제공 해 이상 을 피 하거나 처리 할 수 있 도록 하기 위해 서다.자바 doc 에 @ throws 성명 을 추가 하고 이상 한 장면 을 던 지 는 것 을 설명 합 니 다.

public void doSomething(String input) throws MyBusinessException {
    ...
}

4. 설명 메시지 로 이상 던 지기
이상 을 던 질 때 는 가능 한 한 문제 와 관련 정 보 를 정확하게 묘사 해 야 한다. 그러면 로그 에 인쇄 되 든 감시 도구 에 인쇄 되 든 쉽게 읽 히 고 구체 적 인 오류 정보, 오류 의 심각 성 등 을 잘 찾 을 수 있다.
그러나 잘못된 정보 에 대해 장광설 을 늘 어 놓 겠 다 는 것 은 아니다. 원래 Exception 의 유형 명 이 잘못된 원인 을 반영 할 수 있 기 때문에 한두 마디 로 만 설명 하면 된다.
만약 특정한 이상 을 던진다 면, 그 종류의 이름 은 이미 이런 오 류 를 묘 사 했 을 것 이다.그래서 추가 정 보 를 많이 제공 할 필요 가 없다.좋 은 예 는 NumberFormat Exception 입 니 다.잘못된 형식 으로 String 을 제공 할 때 자바. lang. Long 류 의 구조 함수 에 의 해 던 집 니 다.

try {
    new Long("xyz");
} catch (NumberFormatException e) {
    log.error(e);
}

5. 가장 구체 적 인 이상 포착 우선
대부분의 IDE 는 당신 이 이 최고의 실천 을 실현 하 는 데 도움 을 줄 수 있 습 니 다.구체 적 이지 않 은 이상 을 먼저 포착 하려 고 시도 할 때 접근 할 수 없 는 코드 블록 을 보고 합 니 다.
문 제 는 이상 한 첫 번 째 catch 블록 만 실 행 될 수 있다 는 점 이다.따라서 Illegal Argument Exception 을 먼저 캡 처 하면 더 구체 적 인 NumberFormat Exception 을 처리 해 야 할 catch 블록 에 도달 하지 못 합 니 다. Illegal Argument Exception 의 하위 클래스 이기 때 문 입 니 다.
항상 가장 구체 적 인 이상 류 를 우선 포착 하고 구체 적 이지 않 은 catch 블록 을 목록 의 끝 에 추가 합 니 다.
아래 코드 세 션 에서 try - catch 문장의 예 를 볼 수 있 습 니 다.첫 번 째 catch 블록 은 모든 NumberFormat Exception 이상 을 처리 하고, 두 번 째 는 NumberFormat Exception 이상 이 아 닌 IllegalArgument Exception 이상 을 처리 합 니 다.

public void catchMostSpecificExceptionFirst() {
    try {
        doSomething("A message");
    } catch (NumberFormatException e) {
        log.error(e);
    } catch (IllegalArgumentException e) {
        log.error(e)
    }
}

6. Throwable 클래스 를 포획 하지 마 세 요
Throwable 은 모든 이상 과 오류 의 초 클래스 입 니 다.너 는 catch 자구 에서 그것 을 사용 할 수 있 지만, 너 는 영원히 이렇게 해 서 는 안 된다!
catch 자구 에서 Throwable 을 사용 하면 모든 이상 을 포착 할 뿐만 아니 라 모든 오 류 를 포착 할 수 있 습 니 다.JVM 은 오 류 를 던 져 응용 프로그램 이 처리 해 서 는 안 될 심각 한 문 제 를 지적 했다.전형 적 인 예 는 OutOf Memory Error 나 Stack Overflow Error 다.둘 다 응용 프로그램 제어 이외 의 상황 으로 인해 발생 하여 처리 할 수 없다.
따라서 특수 한 상황 에서 오 류 를 처리 할 수 있다 고 확신 하지 않 는 한 Throwable 을 잡지 않 는 것 이 좋 습 니 다.

public void doNotCatchThrowable() {
    try {
        // do something
    } catch (Throwable t) {
        // don't do this!
    }
}

7. 이상 을 무시 하지 마라
개발 자 들 은 이상 을 던 지지 않 을 자신 이 있어 서 catch 블록 을 썼 지만 로 그 를 처리 하거나 기록 하지 않 았 습 니 다.

public void doNotIgnoreExceptions() {
    try {
        // do something
    } catch (NumberFormatException e) {
        // this will never happen
    }
}

그러나 현실 은 예측 할 수 없 는 이상 이 자주 발생 하거나 이곳 의 코드 가 앞으로 바 뀔 지 확인 할 수 없 는 경우 가 많다.
합 리 적 인 방법 은 적어도 이상 한 정 보 를 기록 하 는 것 이다.

但现实是经常会出现无法预料的异常，或者无法确定这里的代码未来是不是会改动(删除了阻止异常抛出的代码)，而此时由于异常被捕获，使得无法拿到足够的错误信息来定位问题。

合理的做法是至少要记录异常的信息。

8. 이상 을 기록 하고 던 지지 마 세 요
이것 은 아마도 본문 에서 가장 자주 무시 되 는 가장 좋 은 실천 일 것 이다.많은 코드, 심지어 라 이브 러 리 에 이상 을 포착 하고 로 그 를 기록 하 며 다시 던 지 는 논리 가 있 음 을 발견 할 수 있다.다음 과 같다.

try {
    new Long("xyz");
} catch (NumberFormatException e) {
    log.error(e);
    throw e;
}

이 처리 논 리 는 보기에 합리적이다.하지만 이 는 같은 이상 출력 여러 로 그 를 자주 출력 합 니 다.다음 과 같다.

17:44:28,945 ERROR TestExceptionHandling:65 - java.lang.NumberFormatException: For input string: "xyz"
Exception in thread "main" java.lang.NumberFormatException: For input string: "xyz"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Long.parseLong(Long.java:589)
at java.lang.Long.(Long.java:965)
at com.stackify.example.TestExceptionHandling.logAndThrowException(TestExceptionHandling.java:63)
at com.stackify.example.TestExceptionHandling.main(TestExceptionHandling.java:58)

위 에서 보 듯 이 뒤의 로그 에 도 더 유용 한 정보 가 추가 되 지 않 았 다.더 유용 한 정 보 를 제공 하려 면 이상 을 사용자 정의 이상으로 포장 할 수 있 습 니 다.

public void wrapException(String input) throws MyBusinessException {
    try {
        // do something
    } catch (NumberFormatException e) {
        throw new MyBusinessException("A message that describes the error.", e);
    }
}

따라서 이상 을 처리 하려 고 할 때 만 캡 처 합 니 다. 그렇지 않 으 면 방법 서명 에서 호출 자 를 처리 하 라 고 성명 해 야 합 니 다.
9. 포장 이상 시 원래 의 이상 을 버 리 지 마 세 요
표준 이상 을 포착 하고 사용자 정의 이상 으로 포장 하 는 것 은 흔 한 방법 이다.이렇게 하면 더욱 구체 적 인 이상 정 보 를 추가 하고 맞 춤 형 이상 처 리 를 할 수 있다.
이렇게 할 때 원본 이상 을 원인 으로 설정 하 는 지 확인 하 십시오.Exception 클래스 는 특수 한 구조 함수 방법 을 제공 합 니 다. Throwable 을 매개 변수 로 받 아들 입 니 다.그렇지 않 으 면 스 택 추적 과 원본 이상 정 보 를 잃 어 버 려 이상 한 사건 을 분석 하 는 데 어려움 을 겪 게 될 것 입 니 다.

public void wrapException(String input) throws MyBusinessException {
    try {
        // do something
    } catch (NumberFormatException e) {
        throw new MyBusinessException("A message that describes the error.", e);
    }
}

10. 이상 제어 프로그램의 절 차 를 사용 하지 마 십시오.
이상 제어 응용의 실행 절 차 를 사용 해 서 는 안 된다. 예 를 들 어 if 문 구 를 사용 하여 조건 판단 을 해 야 하 는 상황 에서 이상 처 리 를 사용 하 는 것 은 매우 나 쁜 습관 이 고 응용 성능 에 심각 한 영향 을 줄 수 있다.
11. 사용 기준 이상
내 장 된 이상 을 사용 하면 문 제 를 해결 할 수 있다 면 자신의 이상 을 정의 하지 마 세 요.자바 API 는 서로 다른 상황 에 대한 수백 가지 이상 유형 을 제공 합 니 다. 개발 에 있어 서 자바 API 가 제공 하 는 이상 을 가능 한 한 사용 합 니 다. 표준 이상 이 당신 의 요 구 를 만족 시 키 지 못 하면 이 때 자신의 맞 춤 형 이상 을 만 듭 니 다.가능 한 한 표준 이상 을 사용 하면 새로 가입 한 개발 자가 프로젝트 코드 를 이해 하 는 데 유리 하 다.
12. 이상 은 성능 에 영향 을 미친다
이상 처리 의 성능 비용 이 매우 높 기 때문에 모든 자바 프로그래머 들 은 개발 할 때 이 말 을 명심 해 야 한다.하나의 이상 을 만 드 는 것 이 매우 느 리 고 하나의 이상 을 던 지면 1 ~ 5ms 가 소모 되 며 하나의 이상 이 응용 되 는 여러 등급 사이 에 전 달 될 때 전체 응용 성능 에 영향 을 줄 수 있 습 니 다.
이상 한 상황 에서 만 이상 사용 하기;
회복 가능 한 이상 상황 에서 이상 사용 하기;
자바 개발 에 매우 유리 하지만 응용 프로그램 에서 너무 많은 호출 스 택 을 포착 하지 않 는 것 이 좋 습 니 다. 많은 경우 에 호출 스 택 을 인쇄 하지 않 아 도 어디 가 잘못 되 었 는 지 알 수 있 기 때 문 입 니 다.따라서 이상 소식 은 적절 한 정 보 를 제공 해 야 한다.