Throwable, Error, Exception, RuntimeException 차별화

1. Throwable 클래스는 Java 언어의 모든 오류 또는 예외 클래스입니다.그것의 두 하위 클래스는 Error와 Exception이다.
2. Error는 Throwable의 하위 클래스로 합리적인 응용 프로그램이 포획을 시도하지 말아야 할 심각한 문제를 표시하는 데 사용됩니다.대다수의 이런 잘못은 모두 이상 조건이다.ThreadDeath 오류는'정규적'조건이지만, 대부분의 응용 프로그램에서 포획을 시도해서는 안 되기 때문에 오류의 하위 클래스이기도 합니다.이 방법을 실행하는 동안, throws 자구에서 던질 수 있지만 포획할 수 없는 Error의 하위 클래스를 성명할 필요가 없습니다. 이 오류는 다시는 발생하지 않을 이상 조건이 될 수 있기 때문입니다.
3. Exception 클래스와 그 하위 클래스는 Throwable의 한 형식으로 합리적인 응용 프로그램이 포획하고자 하는 조건을 가리킨다.
4. Runtime Exception은 Java 가상 머신이 정상적으로 작동하는 동안 던질 수 있는 이상한 클래스입니다.실행 방법 중에 던져졌지만 잡히지 않은 Runtime Exception의 모든 하위 클래스는throws 자구에 설명할 필요가 없습니다.이것은 Exception의 하위 클래스입니다.
5. 방법을 다시 쓸 때: 하위 클래스에서 다시 쓰는 방법은 상위 클래스에서 설명한 이상이나 이상한 하위 클래스만 던질 수 있습니다

Error와 Exception의 차이점은 무엇입니까?

Error 클래스와 Exception 클래스는 Throwable 클래스에서 상속됩니다.

Error의 상속 관계:

java.lang.Object  java.lang.Throwable       java.lang.Error
 

Exception의 계승 관계:

java.lang.Objectjava.lang.Throwable      java.lang.Exception
 
 
양자의 차이점:
 
Exception: 1. 제어할 수 있거나 제어할 수 없는 (unchecked) 2. 프로그래머로 인한 오류를 나타냅니다.
 
Error:1. 항상 제어할 수 없는 (unchecked)2. 시스템 오류나 저층 자원의 오류를 나타내는 데 자주 사용됩니다.
 
 
 
Java에는 다음과 같은 두 가지 예외가 정의되어 있습니다.
1) Checked exception: 이러한 이상은 모두 Exception의 하위 클래스입니다.이상 상향 던지기 메커니즘을 처리합니다. 만약에 하위 클래스에 A 이상이 발생할 수 있다면 상위 클래스에서도throws A 이상이 있어야 합니다.발생할 수 있는 문제: 코드 효율이 낮고 결합도가 너무 높다.2) Unchecked exception: 이런 이상은 모두 Runtime Exception의 하위 클래스입니다. Runtime Exception 역시 Exception의 하위 클래스이지만 비범합니다. 클라이언트 코드를 통해 해결하려고 할 수 없기 때문에 Unchecked exception이라고 합니다.
 
 
Java의 이상 클래스에 대한 상속 관계도:
 

Checked Exception과 Runtime Exception의 차이점

Java에서 중요한 특징은 Exception이다. 즉, 프로그램에 예외적인 상황이 생기도록 허락하는 것이다.자바를 배울 때 우리도 Exception의 작법만 알고 있지만 서로 다른 종류의 Exception의 차이를 이해할 수 있는 것은 아니다.
우선, 자바는 두 가지 Exception 모드를 제공합니다. 하나는 실행할 때 발생하는 Exception(Runtime Exception)이고, 다른 하나는 제어되는 Exception(Checked Exception)입니다.
모든 Checked Exception은 java에서 실행됩니다.lang. Exception은 상속되고, Runtime Exception은 자바를 상속합니다.lang.RuntimeException 또는java.lang. Error (실제로는 java.lang.Runtime Exception의 윗층도 java.lang.Exception) 입니다.
우리가 프로그램을 작성할 때, 우리는 어떤 형식의 Exception을 선택하는 것에 대해 괴로움을 느낄 수 있다. 도대체 나는 Runtime Exception을 선택해야 하는가, 아니면 Checked Exception을 선택해야 하는가?
사실, 운영에 있어서, 우리는 Class의 Method를 통해 어떤 Exception을 어떻게 생성하는지, 그리고 어떤 프로그램이 이 생성된 Exception을 어떻게 처리하는지 그것들 사이의 차이를 이해할 수 있다.
일단 저희가 Exception을 하나 만들어보도록 하겠습니다.

public class CException extends Exception {
	public CException() {
	}

	public CException(String message) {
		super(message);
	}
}

그리고 저희가 CException이 생길 수 있는 클래스를 하나 쓰도록 하겠습니다.

public class TestException {
	public void method1() throws CException {
		throw new CException("Test Exception");
	}

	public void method2(String msg) {
		if (msg == null) {
			throw new NullPointerException("Message is null");
		}
	}

	public void method3() throws CException {
		method1();
	}

	//  
	// ...
}

이 세 개의 method에서 우리는 method1과 method2의 프로그램 코드에서 모두 Exception이 발생하는 것을 보았지만, method3의 프로그램 코드에서 (대괄호 안에) Exception이 발생하지 않았지만, method3의 정의에서 이 method가 CException을 생성할 수 있음을 암시했다.
method1()을 호출하는 프로그램은 try와catch에 method1()을 포함해야 합니다.

public class Runtest {
	// ....
	public static void main(String argv[]) {
		TestException te = new TestException();
		try {
			te.method1();
		} catch (CException ce) {
			// ....
			ce.printStackTrace();
		}
	}
	// ...
}

try와catch에 포함되어 있지만 이 프로그램 코드가 반드시 CException을 받을 것이라고 표시하지는 않지만, 호출자에게 이 메서드를 실행하는 데 발생할 수 있는 의외의 결과를 알려 주고, 사용자도 이 의외에 대해 대응하는 처리 방식을 만들어야 한다는 뜻이다.
사용자가 method2 () 를 호출할 때, try와catch를 사용하여 프로그램 코드를 패키지할 필요가 없습니다. method2의 정의에는throws의 Exception이 없습니다. 예를 들어:

public class Runtest
{
// ....
public static void main(String argv[])
{

testException te = new testException();

//   Exception
te.method2("Hello");

//   Exception
te.method2(null);
}
// ...
}

프로그램이 실행될 때 Null Pointer Exception이 실제로 생성되는 것도 아니다. 이런 Exception을 런타임 exception이라고 하고 unchecked exception이라고 하는데 런타임 exception을 생성하는 method(이 예에서 method2)는 method를 선언할 때 어떤 Exception이 생성될지 정의할 필요가 없다.
testException의method3()에서 우리는 다른 상황, 즉 method3에서method1()을 호출했지만 method1을try와catch 사이에 패키지하지 않았습니다.반면,method3()의 정의에서 이것은 CException을 정의합니다. 실제로는 method3가 CException을 받으면 이 CException을 처리하지 않고 밖으로 던집니다.물론,method3의 정의에throwsCException이 있기 때문에,method3를 호출하는 프로그램 코드도trycatch가 있어야 합니다.
따라서 프로그램의 운영 메커니즘에서 볼 때 Runtime Exception은 Checked Exception과 다르지만 논리적으로 볼 때 Runtime Exception과 Checked Exception은 사용 목적도 다르다.
일반적으로 Checked Exception은 이 Exception이 처리되어야 한다는 것을 나타낸다. 즉, 프로그래머는 어떤 Exception(try catch가 살아야 하기 때문에)을 받을 수 있다는 것을 알고 있기 때문에 프로그래머는 이러한 서로 다른 Checked Exception에 대해 다른 처리를 할 수 있어야 한다.
Runtime Exception은 일반적으로 프로그램의 오류를 암시하는데, 이러한 오류는 프로그래머가 처리할 수 없고, 프로그램을 계속 실행할 수 없게 만든다.
다음 예를 참조하십시오.
String message[] = {"message1", "message2","message3"};
System.out.println(message[3]);
이 프로그램 코드는 Compile에서 문제가 없지만 실행할 때 Array Index OfBound Exception의 예외가 발생합니다. 이런 상황에서 우리는 이 Runtime Exception에 대해 의미 있는 동작을 할 수 없습니다. 이것은 우리가 테스트 Exception의 method2를 호출하여 Null Pointer Exception을 일으킨 것과 같습니다. 이런 상황에서 우리는 프로그램 코드를 수정해야 합니다.이 문제를 피하다.
따라서 실제로 우리도 모든 Checked Exception을 잡아야 하며, 프로그램이 서로 다른 상황에 직면할 수 있도록 이러한 Checked Exception이 발생할 때 상응하는 처리를 하는 것이 가장 좋다.
그러나 Runtime Exception에 대해 어떤 사람들은 그것을 캐치하고 다른 곳으로 안내하여 프로그램이 계속 실행되도록 하는 것을 건의한다. 이런 방법은 결코 좋지 않다. 그러나 이것은 우리로 하여금 어떤 테스트 도구에서 우리의 프로그램 코드에 문제가 없다고 생각하게 할 것이다. 왜냐하면 우리는 Runtime Exception을'처리'했기 때문이다. 사실은 그렇지 않기 때문이다.예를 들어 많은 사람들의 습관은 프로그램의 진입점 뒤에 큰 trycatch로 포장하는 것이다. 예를 들어

public class Runtest1 {
	public static void main(String argv[]) {
		try {
			// ...
		} catch (Exception e) {
		}
	}
}

이런 상황에서 우리는 어떤 Exception이 발생했거나 어느 줄에서 보냈는지 알 수 없기 때문에 서로 다른 Checked Exception에 직면했을 때, 우리는 각각trycatch에 갔다.테스트 단계에서 만약에 Runtime Exception에 부딪히면 우리는 그것을 이렇게 발생시킬 수 있다. 이어서 우리의 프로그램 코드를 수정해서 Runtime Exception을 피할 수 있도록 해야 한다. 그렇지 않으면 우리는 모든 Exception을 꼼꼼히 따져야 한다. 그것이 Runtime Exception이 없을 때까지!
Checked Exception과 Runtime Exception에 대해 많은 사람들이 다른 관점을 가지고 있을 것이라고 생각합니다. 어쨌든 프로그램이 먼저 실행될 수 있어야 이런 Exception이 생길 수 있습니다.따라서 우리는 이러한 Exception을 Bug로 간주할 수도 있고, 다른 상황(Checked Exception)으로 간주할 수도 있고, 잘못된 것을 제거하는 도구(Runtime Exception)로 간주할 수도 있지만, 전제 조건은 우리가 이러한 Exception을 처리해야 한다는 것이다. 처리하지 않으면 문제나 상황은 영원히 거기에 남아 있을 것이다.