java.lang.Error를 언제 잡을까요?

어떤 상황 java.lang.Error에서 애플리케이션을 포착해야 합니까?

일반적으로 결코.

그러나 때로는 특정 오류를 포착해야합니다.

프레임 워크와 같은 코드를 작성하는 경우 (타사 클래스로드), 잡는 것이 현명 할 수 있습니다. LinkageError (클래스 정의 없음, 만족스럽지 않은 링크, 호환되지 않는 클래스 변경).

나는 또한의 서브 클래스를 던지는 어리석은 써드 파티 코드를 보았습니다 Error.

그건 그렇고,에서 복구 할 수 없는지 잘 모르겠습니다 OutOfMemoryError.

못. 응용 프로그램이 다음 코드 줄을 실행할 수 있는지 확신 할 수 없습니다. 를 받으면 어떤 일이든 안정적으로 할 수 있다는 보장OutOfMemoryError 이 없습니다 . RuntimeException을 잡아 예외를 확인했지만 오류는 확인하지 않았습니다.

http://pmd.sourceforge.net/rules/strictexception.html

일반적으로 항상 java.lang.Error로그에 기록하거나 사용자에게 표시해야합니다. 저는 지원팀에서 일하며 프로그래머가 프로그램에서 무슨 일이 일어 났는지 말할 수 없다는 것을 매일 봅니다.

데몬 스레드가있는 경우 종료되는 것을 방지해야합니다. 다른 경우에는 응용 프로그램이 올바르게 작동합니다.

java.lang.Error최고 수준 에서만 잡을 수 있습니다.

오류 목록을 보면 대부분 처리 할 수 ​​있음을 알 수 있습니다. 예를 들어 a ZipError는 손상된 zip 파일을 읽을 때 발생합니다.

가장 일반적인 오류는 OutOfMemoryError및이며 NoClassDefFoundError, 대부분의 경우 런타임 문제입니다.

예를 들면 :

int length = Integer.parseInt(xyz);
byte[] buffer = new byte[length];

생성 할 수 OutOfMemoryError있지만 런타임 문제이며 프로그램을 종료 할 이유가 없습니다.

NoClassDefFoundError라이브러리가 없거나 다른 Java 버전으로 작업하는 경우 대부분 발생합니다. 프로그램의 선택적 부분 인 경우 프로그램을 종료해서는 안됩니다.

Throwable최상위 수준에서 포착 하고 유용한 오류 메시지를 생성하는 것이 좋은 생각 인 이유에 대한 더 많은 예를 제공 할 수 있습니다 .

다중 스레드 환경에서 가장 자주 포착하고 싶어합니다! 당신이 그것을 잡으면 그것을 기록하고 전체 응용 프로그램을 종료하십시오! 그렇게하지 않으면 중요한 부분을 수행 할 수있는 일부 스레드가 죽고 나머지 응용 프로그램은 모든 것이 정상이라고 생각합니다. 그 중에서 원하지 않는 상황이 많이 발생할 수 있습니다. 가장 작은 문제 중 하나는 다른 스레드가 하나의 스레드가 작동하지 않아 일부 예외를 던지기 시작하면 문제의 원인을 쉽게 찾을 수 없다는 것입니다.

예를 들어, 일반적으로 루프는 다음과 같아야합니다.

try {
   while (shouldRun()) {
       doSomething();
   }
}
catch (Throwable t) {
   log(t);
   stop();
   System.exit(1);
}

어떤 경우에도 다른 오류를 다르게 처리하기를 원할 것입니다. 예를 들어 OutOfMemoryError에서는 애플리케이션을 정기적으로 닫을 수 있고 (일부 메모리를 확보하고 계속할 수도 있음) 다른 일부에서는 수행 할 수있는 작업이 많지 않습니다.

아주 드물게.

스레드가 죽는 이유가있는 메시지를 발행하기 위해 스레드의 최상위 수준에서만 말하고 싶습니다.

이런 종류의 작업을 수행하는 프레임 워크에 있다면 프레임 워크에 맡기십시오.

거의 없다. 오류는 응용 프로그램이 일반적으로 수행 할 수없는 문제로 설계되었습니다. 유일한 예외는 오류 표시를 처리하는 것이지만 오류에 따라 계획대로 진행되지 않을 수도 있습니다.

는 Error발생하지 않아야하는 비정상적인 상태를 나타내 므로 일반적으로 잡히면 안됩니다. .

Error클래스에 대한 Java API 사양에서 :

An Error은 Throwable 합리적인 응용 프로그램이 포착하려고하지 않아야하는 심각한 문제를 나타내는 의 하위 클래스입니다 . 이러한 오류는 대부분 비정상 상태입니다. [...]

메서드는 throws 절에서 메서드 실행 중에 throw 될 수 있지만 포착되지 않은 Error의 하위 클래스를 선언 할 필요가 없습니다. 이러한 오류는 발생해서는 안되는 비정상적인 조건이기 때문입니다.

사양에서 언급했듯이 Error는 가능성이있는 상황에서만 발생하며, Error발생시 응용 프로그램이 수행 할 수있는 작업이 거의 없으며 일부 상황에서는 Java Virtual Machine 자체가 불안정한 상태 (예 :VirtualMachineError )

an Error은 절에 Throwable의해 잡힐 수 있음을 의미 하는 하위 클래스 try-catch이지만 응용 프로그램이 비정상 상태에있을 때 실제로 필요하지는 않습니다.Error JVM에 의해 발생합니다.

Section 11.5 The Exception Hierarchy of the Java Language Specification, 2nd Edition 에도이 주제에 대한 짧은 섹션이 있습니다.

새로운 단위 테스트 프레임 워크를 만드는 데 충분히 미쳤다면 테스트 실행기는 테스트 케이스에서 발생하는 java.lang.AssertionError를 잡아야 할 것입니다.

그렇지 않으면 다른 답변을 참조하십시오.

그리고 오류를 발견하면 다시 던져야 하는 몇 가지 다른 경우가 있습니다 . 예를 들어 ThreadDeath 는 절대 잡히지 않아야합니다. 포함 된 환경 (예 : 응용 프로그램 서버)에서 잡으면 큰 문제가 발생할 수 있습니다.

응용 프로그램은 비동기 적으로 종료 된 후 정리해야하는 경우에만이 클래스의 인스턴스를 포착해야합니다. ThreadDeath가 메서드에 의해 잡히면 스레드가 실제로 죽도록 다시 throw되는 것이 중요합니다.

아주 드물게.

나는 아주 특정한 한 가지 알려진 경우에만 그것을했다. 예를 들어, 두 개의 독립 ClassLoader가 동일한 DLL을로드하는 경우 java.lang.UnsatisfiedLinkError가 발생할 수 있습니다 . (JAR를 공유 클래스 로더로 이동해야한다는 데 동의합니다)

그러나 가장 일반적인 경우는 사용자가 불만을 제기했을 때 무슨 일이 일어 났는지 알기 위해 로깅이 필요하다는 것입니다. 사용자에게 메시지 나 팝업이 표시되기를 원합니다.

C / C ++의 프로그래머조차도 오류를 표시하고 종료하기 전에 사람들이 이해하지 못하는 것을 알려줍니다 (예 : 메모리 오류).

Android 애플리케이션에서 java.lang.VerifyError를 포착하고 있습니다 . 내가 사용중인 라이브러리는 이전 버전의 OS가 설치된 장치에서 작동하지 않으며 라이브러리 코드에서 이러한 오류가 발생합니다. 물론 런타임에 OS 버전을 확인하여 오류를 피할 수 있지만 :

• 지원되는 가장 오래된 SDK는 향후 특정 라이브러리에 대해 변경 될 수 있습니다.
• try-catch 오류 블록은 더 큰 폴백 메커니즘의 일부입니다. 일부 특정 장치는 라이브러리를 지원해야하지만 예외를 발생시킵니다. 대체 솔루션을 사용하기 위해 VerifyError 및 모든 예외를 포착합니다.

테스트 환경에서 java.lang.AssertionError를 잡는 것은 매우 편리합니다 ...

이상적으로는 오류를 처리 / 캐치하지 않아야합니다. 그러나 프레임 워크 나 응용 프로그램의 요구 사항에 따라해야 할 경우가있을 수 있습니다. 더 많은 메모리를 소비 하는 DOM 파서 를 구현하는 XML 파서 데몬이 있다고 가정 해 보겠습니다 . Parser 쓰레드가 OutOfMemoryError를 받았을 때 죽지 말아야한다는 요구 사항이 있다면 , 대신 그것을 처리하고 애플리케이션 / 프레임 워크 관리자에게 메시지 / 메일을 보내야합니다.

이상적으로는 비정상적인 조건이므로 Java 애플리케이션에서 오류를 포착해서는 안됩니다. 응용 프로그램이 비정상적인 상태에 있고 캐싱이 발생하거나 심각한 잘못된 결과를 초래할 수 있습니다.

어설 션이 만들어 졌는지 확인하는 단위 테스트 내에서 오류를 포착하는 것이 적절할 수 있습니다. 누군가 어설 션을 비활성화하거나 그렇지 않으면 알고 싶은 어설 션을 삭제하는 경우

JVM이 더 이상 예상대로 작동하지 않거나 직전에있는 경우 오류가 발생합니다. 오류를 발견하면 catch 블록이 실행된다는 보장이 없으며 끝까지 실행될 것이라는 보장도 없습니다.

또한 실행중인 컴퓨터, 현재 메모리 상태에 따라 달라 지므로 최선을 다해 테스트하고 시도 할 방법이 없습니다. 당신은 끔찍한 결과를 얻을 것입니다.

또한 코드의 가독성도 저하됩니다.