1. 위의 사항은 확인 된 예외로 간주됩니까? 아니 당신이 예외를 처리하는 사실은 그것은하지 않습니다 Checked Exception그것은 경우 RuntimeException.

2. 가 RuntimeException은 unchecked exception? 예

Checked Exceptions이다 subclasses의 java.lang.Exception
Unchecked Exceptions이다 subclasses의java.lang.RuntimeException

확인 된 예외를 던지는 호출은 try {} 블록으로 묶거나 메소드의 호출자에서 위 레벨에서 처리되어야합니다. 이 경우 현재 메소드는 호출자가 예외를 처리하기 위해 적절한 조치를 취할 수 있도록 해당 예외를 처리한다고 선언해야합니다.

도움이 되었기를 바랍니다.

Q : 정확한 예외를 버블 링하거나 예외를 사용하여 마스킹해야합니까?

A : 그렇습니다. 이것은 매우 좋은 질문이며 중요한 디자인 고려 사항입니다. Exception 클래스는 매우 일반적인 예외 클래스이며 내부 하위 수준 예외를 래핑하는 데 사용할 수 있습니다. 사용자 정의 예외를 작성하고 그 안에 랩핑하는 것이 좋습니다. 그러나 큰 문제는 근본적인 근본 원인을 절대 모호하게하지 않습니다. 예를 들어 Don't ever다음을 수행하십시오.

try {
     attemptLogin(userCredentials);
} catch (SQLException sqle) {
     throw new LoginFailureException("Cannot login!!"); //<-- Eat away original root cause, thus obscuring underlying problem.
}

대신 다음을 수행하십시오.

try {
     attemptLogin(userCredentials);
} catch (SQLException sqle) {
     throw new LoginFailureException(sqle); //<-- Wrap original exception to pass on root cause upstairs!.
}

원래 근본 원인을 제거하면 복구를 넘어 실제 원인이 사라지는 것은 프로덕션 지원 팀에게 악의적입니다. 응용 프로그램 로그 및 오류 메시지 만 액세스 할 수 있습니다. 후자는 더 나은 디자인이지만 개발자가 기본 메시지를 발신자에게 전달하지 못하기 때문에 많은 사람들이 자주 사용하지 않습니다. 따라서 Always pass on the actual exception응용 프로그램 별 예외에 싸여 있는지 여부를 확인 하십시오 .

시선 잡기 RuntimeExceptions

RuntimeException일반적으로 s는 시도되지 않아야합니다. 그것들은 일반적으로 프로그래밍 오류를 알리기 때문에 혼자 두어야합니다. 대신 프로그래머는 오류가 발생할 수있는 일부 코드를 호출하기 전에 오류 조건을 확인해야합니다 RuntimeException. 예를 들어 :

try {
    setStatusMessage("Hello Mr. " + userObject.getName() + ", Welcome to my site!);
} catch (NullPointerException npe) {
   sendError("Sorry, your userObject was null. Please contact customer care.");
}

이것은 나쁜 프로그래밍 관행입니다. 대신 null 점검은 다음과 같이 수행되어야합니다.

if (userObject != null) {
    setStatusMessage("Hello Mr. " + userObject.getName() + ", Welome to my site!);
} else {
   sendError("Sorry, your userObject was null. Please contact customer care.");
}

그러나 숫자 형식과 같은 오류 검사가 비싼 경우가 있습니다.

try {
    String userAge = (String)request.getParameter("age");
    userObject.setAge(Integer.parseInt(strUserAge));
} catch (NumberFormatException npe) {
   sendError("Sorry, Age is supposed to be an Integer. Please try again.");
}

여기서 사전 호출 오류 검사는 parseInt () 메서드 내에서 모든 문자열-정수 변환 코드를 복제하는 것을 의미하기 때문에 노력할 가치가 없으며 개발자가 구현하면 오류가 발생하기 쉽습니다. 따라서 try-catch를 사용하지 않는 것이 좋습니다.

그래서 NullPointerException하고 NumberFormatException모두 RuntimeExceptions하는 잡는 것은 NullPointerException내가 잡기 권장하면서 우아한 널 (null) 검사로 대체해야 NumberFormatException오류가 발생하기 쉬운 코드의 도입 가능성을 방지하기 위해 명시 적으로.

답변

String s = "abc";
Object o = s;
Integer i = (Integer) o;

Exception in thread "main" java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Integer
    at Sample.main(Sample.java:9)