일부 개발자가 Java의 확인 예외를 반대하는 이유는 무엇입니까?

확인된 예외에 대한 반대

수년 동안 나는 다음 질문에 대해 적절한 답을 얻을 수 없었습니다. 일부 개발자는 왜 그렇게 반대합니까? 이상하게 확인됐나요? 나는 여러 대화를 나누고, 블로그 게시물을 읽고, Bruce Eckel의 관점을 읽었습니다(그는 내가 본 첫 번째 사람입니다).

현재 새로운 코드를 작성 중인데 예외 처리 방법에 매우 주의하고 있습니다. 나는 "우리는 확인된 예외를 좋아하지 않는다"는 군중의 관점을 이해하려고 노력하고 있지만 여전히 이해할 수 없습니다.

모든 대화는 답도 없이 같은 질문으로 끝났습니다... 설정해 보겠습니다:

일반적으로 말하면 (Java 설계에 따라)

• Error는 절대로 잡아서는 안 되는 일에 사용됩니다(VM이 땅콩에 알레르기가 있고 누군가 그 위에 땅콩 한 병을 쏟았습니다)
• RuntimeException은 프로그래머가 잘못한 일에 사용됩니다(프로그래머가 배열 끝에서 나옴)
• 프로그래머의 제어 범위를 벗어나는 예외(RuntimeException 제외)가 사용됩니다(파일 시스템에 쓰는 동안 디스크가 꽉 찼고, 프로세스의 파일 핸들 한계에 도달했으며 더 이상 파일이 없습니다). 열 수 있음)
• Throwable은 모든 예외 유형의 상위 클래스일 뿐입니다.

예외가 발생하면 개발자가 할 수 있는 일은 프로그램을 종료하는 것뿐이라는 말을 자주 듣습니다.

내가 듣는 또 다른 일반적인 주장은 확인된 예외로 인해 코드를 리팩터링하기가 더 어렵다는 것입니다.

'그냥 그만뒀다'는 주장은 그만둔다 해도 합당한 오류 메시지를 보여줘야 한다는 뜻이다. 오류 처리만 피한다면 이유를 명확히 밝히지 않고 프로그램이 종료될 때 사용자는 별로 기뻐하지 않을 것입니다.

"리팩토링이 어렵다"는 군중의 경우 이는 적절한 추상화 수준이 선택되지 않았음을 의미합니다. 메소드가 IOException을 발생시킨다고 선언하는 대신, IOException은 현재 상황에 더 적합한 예외로 변환되어야 합니다.

프로그램이 정상적으로 종료되도록 Main을 catch(Exception)(또는 어떤 경우에는 catch(Throwable))으로 래핑하는 데 문제가 없습니다. 하지만 항상 잡아야 하는 특정 예외를 잡아냅니다. 이렇게 하면 최소한 적절한 오류 메시지를 표시하도록 허용합니다.

사람들이 결코 대답하지 않는 질문은 다음과 같습니다.

대신 RuntimeException
하위 클래스를 던지면 예외
, 그런데
무엇을 잡아야 하는지 어떻게 알 수 있나요?

대답이 예외 잡기라면 시스템 예외도 다음과 같은 방식으로 처리하는 것입니다.

Throwable을 잡으면 시스템 예외와 VM 오류를 같은 방식으로 처리하는 것입니다(등등).

대답은 당신이 던져진 예외만 잡는다는 것입니다. 그러면 프로그래머 X가 새로운 예외를 던질 때 어떤 예외가 던져지는지 어떻게 알 수 있나요? 예외를 던지고 그것을 잡는 것을 잊어버리면 어떻게 될까요?

.

스택 추적을 보여주는 프로그램이 잘못되었다고 말하고 싶습니다. 체크 예외를 좋아하지 않는 사람들도 그렇게 생각하지 않나요?

그럼 확인된 예외가 마음에 들지 않는다면 그 이유를 설명해 주실 수 있나요? 그리고 답이 없는 질문에 답하시겠습니까?

두 모델 중 하나를 사용하는 것에 대한 조언을 구하는 것이 아니라 사람들이 Exception 대신 RuntimeException에서 확장하는 이유와 예외를 포착한 다음 다시 발생시키는 이유를 찾고 있습니다. 하나는 메서드에 RuntimeException throw를 추가하는 대신입니다. 확인된 예외를 좋아하지 않는 이유를 알고 싶습니다.

위 내용은 일부 개발자가 Java의 확인 예외를 반대하는 이유는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!