답변:
일반적으로 RuntimeExceptions 는 프로그래밍 방식으로 방지 할 수있는 예외 입니다. 예 NullPointerException, ArrayIndexOutOfBoundException. null메소드를 호출하기 전에 확인하면 NullPointerException발생하지 않습니다. ArrayIndexOutOfBoundException인덱스를 먼저 확인하면 마찬가지로 발생하지 않습니다.RuntimeException컴파일러에서 확인하지 않으므로 깨끗한 코드입니다.
편집 : 요즘 사람들 RuntimeException은 깨끗한 코드를 생성하기 때문에 선호 합니다. 완전히 개인적인 선택입니다.
RuntimeException는 간단하기 때문에 확인 된 예외와 확인되지 않은 예외의 차이점에 대해 생각할 필요가 없기 때문입니다. 런타임 예외를 잡는 것은 끔찍한 아이디어라고 생각합니다 NullPointerException. 예를 들어와 같은 복구 할 수없는 예외를 잡을 수 있기 때문 입니다.
Java에는 두 가지 유형의 예외가 있습니다. 확인 된 예외와 확인되지 않은 예외. 검사 된 예외는 코드에서 명시 적으로 처리해야하지만 검사되지 않은 예외는 명시 적으로 처리 할 필요가 없습니다.
확인 된 예외의 경우 예외를 발생시킬 수있는 코드 주위에 try / catch 블록을 배치하거나 메소드에 "throws"절을 추가하여 메소드가이 유형의 예외를 발생시킬 수 있음을 나타냅니다 ( 호출 클래스 이상에서 처리).
"Exception"에서 파생 된 예외는 확인 된 예외 인 반면 RuntimeException에서 파생 된 클래스는 확인되지 않습니다. 호출 코드가 RuntimeException을 명시 적으로 처리 할 필요는 없습니다.
java.lang.RuntimeException와 java.lang.Exception클래스 의 차이점을 살펴보기 전에 Exception계층 구조 를 알아야합니다 . Exception와 Error클래스는 모두 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 및 해당 서브 클래스)는 컴파일러가 런타임 예외가 발생할 수 없음을 설정할 수 없으므로 컴파일 타임 검사에서 제외됩니다. (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 클래스 클래스 정의 에서 메소드 execute는 RuntimeException을 발생 시킬 수 있지만 메소드 선언은 RuntimeException 을 발생 시키도록 지정할 필요가 없습니다 .
이 메소드 process는 확인 된 예외를 발생 시키며 MyException 종류의 확인 된 예외를 발생 시키며 그렇지 않으면 컴파일 오류가 발생 함을 선언해야합니다 .
위의 클래스 정의는 Process 클래스 를 사용하는 코드에도 영향을 미칩니다 .
이 호출은 new Process().execute()양식의 호출로 유효한 호출입니다
new Process().process()컴파일 오류가 있습니다. 이는 클라이언트 코드가 처리 단계를 수행해야하기 때문입니다 MyException(예 : process () 호출을 try / catch 블록으로 묶을 수 있음).
에서 체크되지 않는 예외 - 논쟁 :
클라이언트가 예외로부터 적절히 복구 될 것으로 예상되는 경우이를 확인 된 예외로 만듭니다. 클라이언트가 예외에서 복구 할 작업을 수행 할 수 없으면 검사되지 않은 예외로 만드십시오.
확인되지 않은 예외는에서 파생 된 RuntimeException예외이고 확인 된 예외는에서 파생 된 예외입니다 Exception.
RuntimeException클라이언트가 예외에서 복구 할 수있는 작업을 수행 할 수없는 경우 왜 발생합니까? 이 기사는 다음을 설명합니다.
런타임 예외는 프로그래밍 문제의 결과로 발생하는 문제를 나타내므로 API 클라이언트 코드는 합리적으로 복구하거나 처리 할 수 없습니다. 이러한 문제에는 0으로 나누는 것과 같은 산술 예외; null 참조를 통해 객체에 액세스하는 등의 포인터 예외; 너무 크거나 작은 인덱스를 통해 배열 요소에 액세스하려는 것과 같은 인덱싱 예외.
오라클 문서에서 :
결론은 다음과 같습니다. 클라이언트가 예외에서 복구 할 것으로 예상되는 경우이를 확인 된 예외로 만듭니다. 클라이언트가 예외에서 복구 할 작업을 수행 할 수 없으면 검사되지 않은 예외로 만드십시오.
런타임 예외는 프로그래밍 문제 의 결과로 발생하는 문제를 나타내 므로 API 클라이언트 코드는 합리적으로 복구하거나 처리 할 수 없습니다.
RuntimeExceptions는 런타임 예외의 예인 "API의 유효하지 않은 사용 예외"와 같습니다. IllegalStateException, NegativeArraySizeException, NullpointerException
예외를 사용하면 복구 할 무언가를 수행 할 수 있으므로 명시 적으로 잡아야합니다. 예외의 예는 다음과 같습니다. IOException, TimeoutException, PrintException ...
RuntimeException은 Exception 클래스의 자식 클래스입니다
이것은 Exception 클래스의 많은 하위 클래스 중 하나입니다. RuntimeException은 Java Virtual Machine의 정상적인 작동 중에 발생할 수있는 예외의 수퍼 클래스입니다. 메소드는 메소드 실행 중에 발생하지만 포착되지 않은 RuntimeException의 서브 클래스를 throws 절에 선언 할 필요는 없습니다.
계층은
java.lang.Object
--- java.lang.Throwable
------- java.lang.Exception
------------- java.lang.RuntimeException
두 가지 유형의 예외가 있습니다. 이러한 종류의 예외가 발생하면 확인 된 예외를 복구 할 수 있습니다. 런타임 예외는 복구 할 수없고 런타임 예외는 프로그래밍 오류이며 프로그래머는 코드를 작성하는 동안이를 처리해야하며이 코드를 계속 실행하면 잘못된 결과가 발생할 수 있습니다. 런타임 예외는 전제 조건을 위반하는 것입니다. 10 크기의 배열이 있고 11 번째 요소에 액세스하려고하면 ArrayIndexOutOfBoundException이 발생합니다.