[java] java.lang.RuntimeException과 java.lang.Exception의 차이점

누군가 java.lang.RuntimeException와 의 차이점을 설명 해주십시오 java.lang.Exception. 내 예외를 만들면 어느 것을 확장 할 것인지 어떻게 결정합니까?



답변

일반적으로 RuntimeExceptions 는 프로그래밍 방식으로 방지 할 수있는 예외 입니다. 예 NullPointerException, ArrayIndexOutOfBoundException. null메소드를 호출하기 전에 확인하면 NullPointerException발생하지 않습니다. ArrayIndexOutOfBoundException인덱스를 먼저 확인하면 마찬가지로 발생하지 않습니다.RuntimeException컴파일러에서 확인하지 않으므로 깨끗한 코드입니다.

편집 : 요즘 사람들 RuntimeException은 깨끗한 코드를 생성하기 때문에 선호 합니다. 완전히 개인적인 선택입니다.


답변

Java에는 두 가지 유형의 예외가 있습니다. 확인 된 예외와 확인되지 않은 예외. 검사 된 예외는 코드에서 명시 적으로 처리해야하지만 검사되지 않은 예외는 명시 적으로 처리 할 필요가 없습니다.

확인 된 예외의 경우 예외를 발생시킬 수있는 코드 주위에 try / catch 블록을 배치하거나 메소드에 “throws”절을 추가하여 메소드가이 유형의 예외를 발생시킬 수 있음을 나타냅니다 ( 호출 클래스 이상에서 처리).

“Exception”에서 파생 된 예외는 확인 된 예외 인 반면 RuntimeException에서 파생 된 클래스는 확인되지 않습니다. 호출 코드가 RuntimeException을 명시 적으로 처리 할 필요는 없습니다.


답변

java.lang.RuntimeExceptionjava.lang.Exception클래스 의 차이점을 살펴보기 전에 Exception계층 구조 를 알아야합니다 . ExceptionError클래스는 모두 class Throwable에서 파생됩니다 Object. 그리고 클래스 RuntimeException는 class 에서 파생됩니다 Exception.

모든 예외는 Exception또는 에서 파생됩니다 RuntimeException.

파생 된 모든 예외 RuntimeException검사되지 않은 예외 라고합니다 . 그리고 다른 모든 예외는 검사 예외입니다. 확인 된 예외는 코드 어딘가에 발견되어야하며, 그렇지 않으면 컴파일되지 않습니다. 이것이 바로 체크 예외라고하는 이유입니다. 반면에, 확인되지 않은 예외를 제외하고 호출 메소드는이를 처리하거나 선언 할 의무가 없습니다.

따라서 컴파일러에서 처리하도록 강제하는 모든 예외는 직접 파생되며 java.lang.Exception컴파일러가 처리하지 않는 다른 모든 예외 는에서 파생됩니다 java.lang.RuntimeException.

다음은 RuntimeException의 알려진 직계 서브 클래스입니다 .

AnnotationTypeMismatchException,
ArithmeticException,
ArrayStoreException,
BufferOverflowException,
BufferUnderflowException,
CannotRedoException,
CannotUndoException,
ClassCastException,
CMMException,
ConcurrentModificationException,
DataBindingException,
DOMException,
EmptyStackException,
EnumConstantNotPresentException,
EventException,
IllegalArgumentException,
IllegalMonitorStateException,
IllegalPathStateException,
IllegalStateException,
ImagingOpException,
IncompleteAnnotationException,
IndexOutOfBoundsException,
JMRuntimeException,
LSException,
MalformedParameterizedTypeException,
MirroredTypeException,
MirroredTypesException,
MissingResourceException,
NegativeArraySizeException,
NoSuchElementException,
NoSuchMechanismException,
NullPointerException,
ProfileDataException,
ProviderException,
RasterFormatException,
RejectedExecutionException,
SecurityException,
SystemException,
TypeConstraintException,
TypeNotPresentException,
UndeclaredThrowableException,
UnknownAnnotationValueException,
UnknownElementException,
UnknownTypeException,
UnmodifiableSetException,
UnsupportedOperationException,
WebServiceException 


답변

예외가 점검되고 RuntimeException이 점검되지 않습니다.

Checked는 컴파일러가 예외를 catch에서 처리하거나 메소드 (또는 수퍼 클래스 중 하나)를 발생시키는 것으로 선언해야 함을 의미합니다.

일반적으로 API 호출자가 예외를 처리 할 것으로 예상되면 확인 된 예외를 발생시키고, 호출자가 일반적으로 처리 할 수없는 것으로 확인되지 않은 예외 (예 : 프로그래밍 중 매개 변수 중 하나의 오류) 잘못.


답변

런타임 예외 클래스 (RuntimeException 및 해당 서브 클래스)는 컴파일러가 런타임 예외가 발생할 수 없음을 설정할 수 없으므로 컴파일 타임 검사에서 제외됩니다. (JLS에서).

디자인 한 클래스에서 예외 를 서브 클래 싱하고 예외를 발생시켜 예외적 인 시나리오 를 알려야합니다 . 그렇게하면 클래스의 클라이언트에게 클래스 사용에 예외가 발생할 수 있음을 명시 적으로 알리게되며 예외적 인 시나리오를 처리하기 위해 조치를 취해야합니다.

아래 코드 스 니펫은이 점을 설명합니다.

//Create your own exception class subclassing from Exception
class MyException extends Exception {
    public MyException(final String message) {
        super(message);
    }
}

public class Process {
    public void execute() {
        throw new RuntimeException("Runtime");
    }
    public void process() throws MyException {
        throw new MyException("Checked");
    }
}

위의 Process 클래스 클래스 정의 에서 메소드 executeRuntimeException을 발생 시킬 수 있지만 메소드 선언은 RuntimeException 을 발생 시키도록 지정할 필요가 없습니다 .

이 메소드 process는 확인 된 예외를 발생 시키며 MyException 종류의 확인 된 예외를 발생 시키며 그렇지 않으면 컴파일 오류가 발생 함을 선언해야합니다 .

위의 클래스 정의는 Process 클래스 를 사용하는 코드에도 영향을 미칩니다 .

이 호출은 new Process().execute()양식의 호출로 유효한 호출입니다
new Process().process()컴파일 오류가 있습니다. 이는 클라이언트 코드가 처리 단계를 수행해야하기 때문입니다 MyException(예 : process () 호출을 try / catch 블록으로 묶을 수 있음).


답변

RuntimeException의 적절한 사용?

에서 체크되지 않는 예외 – 논쟁 :

클라이언트가 예외로부터 적절히 복구 될 것으로 예상되는 경우이를 확인 된 예외로 만듭니다. 클라이언트가 예외에서 복구 할 작업을 수행 할 수 없으면 검사되지 않은 예외로 만드십시오.

확인되지 않은 예외는에서 파생 된 RuntimeException예외이고 확인 된 예외는에서 파생 된 예외입니다 Exception.

RuntimeException클라이언트가 예외에서 복구 할 수있는 작업을 수행 할 수없는 경우 왜 발생합니까? 이 기사는 다음을 설명합니다.

런타임 예외는 프로그래밍 문제의 결과로 발생하는 문제를 나타내므로 API 클라이언트 코드는 합리적으로 복구하거나 처리 할 수 ​​없습니다. 이러한 문제에는 0으로 나누는 것과 같은 산술 예외; null 참조를 통해 객체에 액세스하는 등의 포인터 예외; 너무 크거나 작은 인덱스를 통해 배열 요소에 액세스하려는 것과 같은 인덱싱 예외.


답변

오라클 문서에서 :

결론은 다음과 같습니다. 클라이언트가 예외에서 복구 할 것으로 예상되는 경우이를 확인 된 예외로 만듭니다. 클라이언트가 예외에서 복구 할 작업을 수행 할 수 없으면 검사되지 않은 예외로 만드십시오.

런타임 예외는 프로그래밍 문제 의 결과로 발생하는 문제를 나타내 므로 API 클라이언트 코드는 합리적으로 복구하거나 처리 할 수 ​​없습니다.

RuntimeExceptions는 런타임 예외의 예인 “API의 유효하지 않은 사용 예외”와 같습니다. IllegalStateException, NegativeArraySizeException, NullpointerException

예외를 사용하면 복구 할 무언가를 수행 할 수 있으므로 명시 적으로 잡아야합니다. 예외의 예는 다음과 같습니다. IOException, TimeoutException, PrintException …