프로그래밍 언어/JAVA

자바에서 확인 된 예외와 확인되지 않은 예외 이해

Rateye 2021. 10. 14. 11:58
728x90
반응형
질문 : 자바에서 확인 된 예외와 확인되지 않은 예외 이해

"Effective Java "의 Joshua Bloch는 다음과 같이 말했습니다.

복구 가능한 조건에 대해 확인 된 예외를 사용하고 프로그래밍 오류에 대해 런타임 예외를 사용합니다 (2 판의 항목 58).

내가 이것을 올바르게 이해하는지 보자.

확인 된 예외에 대한 이해는 다음과 같습니다.

try{
    String userInput = //read in user input
    Long id = Long.parseLong(userInput);
}catch(NumberFormatException e){
    id = 0; //recover the situation by setting the id to 0
}

1. 위의 사항이 확인 된 예외로 간주됩니까?

2. RuntimeException이 확인되지 않은 예외입니까?

확인되지 않은 예외에 대한 나의 이해는 다음과 같습니다.

try{
    File file = new File("my/file/path");
    FileInputStream fis = new FileInputStream(file);   
}catch(FileNotFoundException e){

//3. What should I do here?
    //Should I "throw new FileNotFoundException("File not found");"?
    //Should I log?
    //Or should I System.exit(0);?
}

4. 이제 위의 코드도 검사 예외가 될 수 없습니까? 이런 상황을 복구 할 수 있을까요? 할 수 있습니까? (참고 : 세 번째 질문은 catch 안에 있습니다)

try{
    String filePath = //read in from user input file path
    File file = new File(filePath);
    FileInputStream fis = new FileInputStream(file);   
}catch(FileNotFoundException e){
    //Kindly prompt the user an error message
    //Somehow ask the user to re-enter the file path.
}

5. 사람들이 이것을하는 이유는 무엇입니까?

public void someMethod throws Exception{

}

예외가 발생하는 이유는 무엇입니까? 오류를 더 빨리 처리하지 않습니까? 왜 거품이 일어?

6. 정확한 예외를 표시하거나 예외를 사용하여 마스크해야합니까?

아래는 내 독서입니다

Java에서 확인 된 예외는 언제 생성해야하며 런타임 예외 여야합니까?

선택 및 선택되지 않은 예외를 선택하는 경우

답변

많은 사람들은 체크 된 예외 (즉, 명시 적으로 포착하거나 다시 던져야하는 예외)를 전혀 사용해서는 안된다고 말합니다. 예를 들어 C #에서는 제거되었으며 대부분의 언어에는 없습니다. RuntimeException 의 하위 클래스 (확인되지 않은 예외)를 throw 할 수 있습니다.

그러나 확인 된 예외는 유용하다고 생각합니다. API 사용자가 예외 상황을 처리하는 방법을 생각하도록 강제하려는 경우에 사용됩니다 (복구 가능한 경우). 확인 된 예외가 Java 플랫폼에서 과도하게 사용되어 사람들이 싫어하는 것입니다.

여기에 주제에 대한 나의 확장 된 견해가 있습니다 .

특정 질문에 관해서는 :

  1. NumberFormatException 이 확인 된 예외로 간주됩니까?
    아니요. NumberFormatException 이 선택되지 않았습니다 (=는 RuntimeException 하위 클래스 임). 왜? 모르겠어요. isValidInteger(..) 메소드가 있어야합니다)
  2. RuntimeException 은 확인되지 않은 예외입니까?
    네, 맞습니다.
  3. 여기서 무엇을해야합니까?
    이 코드의 위치와 원하는 작업에 따라 다릅니다. UI 레이어에있는 경우-잡아서 경고를 표시합니다. 서비스 계층에 있다면-전혀 포착하지 말고 거품을 내십시오. 예외를 삼키지 마십시오. 대부분의 경우 예외가 발생하면 다음 중 하나를 선택해야합니다.
    • 그것을 기록하고 반환
    • 다시 던짐 (메서드에서 던지도록 선언)
    • 생성자에서 현재 예외를 전달하여 새 예외를 생성합니다.
  4. 이제 위의 코드도 확인 된 예외가 될 수 없습니까? 이런 상황을 복구 할 수 있을까요? 할 수 있습니까?
    그럴 수도 있습니다. 그러나 확인되지 않은 예외도 잡는 것을 막을 수는 없습니다.
  5. 사람들이 throws 절에 Exception 클래스를 추가하는 이유는 무엇입니까?
    사람들이 무엇을 잡을지, 무엇을 다시 던져야하는지 생각하기가 게으 르기 때문입니다. Exception 던지는 것은 나쁜 습관이며 피해야합니다.

 

 

아아, 잡을 때, 다시 던질 때, 체크를 사용할 때, 체크되지 않은 예외를 사용할 때를 결정할 수있는 단일 규칙은 없습니다. 나는 이것이 많은 혼란과 많은 나쁜 코드를 야기한다는 것에 동의합니다. 일반적인 원칙은 Bloch에 의해 명시되어 있습니다 (일부 인용). 그리고 일반적인 원칙은 처리 할 수있는 레이어에 예외를 다시 던지는 것입니다.

출처 : https://stackoverflow.com/questions/6115896/understanding-checked-vs-unchecked-exceptions-in-java
728x90
반응형