이 기사에서는 JVM을 사용하여 Java 예외를 포착하는 방법을 설명합니다. (예시 포함) 참고할만한 가치가 있으니 도움이 필요한 친구들이 참고하시면 좋을 것 같습니다.
1. 예외의 두 가지 주요 요소
(1) 예외 발생
1. 명시적: 애플리케이션이 수동으로 예외를 발생시킵니다. 구체적으로, throw를 사용하여 예외를 발생시킵니다.
2 암시적: Java 가상 머신은 실행할 수 없는 코드에 대해 자동으로 예외를 발생시킵니다.
(권장: Java 튜토리얼)
(2) 예외 캡처
1.코드 블록 시도: 예외 모니터링이 필요한 코드를 표시하는 데 사용됩니다.
2.catch 코드 블록: try 코드 블록 다음에, try 코드 블록에서 트리거된 특정 유형의 예외를 잡는 데 사용됩니다. catch 블록은 포착되는 예외 유형을 선언하는 것 외에도 해당 예외 유형에 대한 예외 처리기를 정의합니다. Java에서는 다양한 유형의 예외를 포착하기 위해 try 코드 블록 뒤에 여러 개의 catch 코드 블록이 올 수 있습니다. Java Virtual Machine은 위에서 아래로 예외 처리기와 일치합니다. 따라서 이전 catch 코드 블록에서 캡처한 예외 유형은 다음 유형을 처리할 수 없습니다. 그렇지 않으면 컴파일러가 오류를 보고합니다.
3.fnally 코드 블록: try 코드 블록과 catch 코드 블록에 이어 실행해야 하는 코드 조각을 선언하는 데 사용됩니다. 이는 개방형 시스템 리소스 닫기와 같은 특정 중요한 정리 코드를 건너뛰지 않도록 설계되었습니다. 일반적인 프로그램 실행에서 이 코드는 try 블록 다음에 실행됩니다. 그렇지 않은 경우, 즉 try 코드 블록이 예외를 트리거할 때 예외가 포착되지 않으면 최종 코드 블록이 직접 실행되고 실행 후 예외가 다시 발생합니다. 예외가 catch 블록에 의해 포착되면 finally 블록은 catch 블록 다음에 실행됩니다. 일부 불행한 상황에서는 catch 블록도 예외를 트리거한 다음 fnally 블록도 실행되어 catch 블록에 의해 트리거된 예외를 발생시킵니다. 매우 불행한 상황에서는 fnally 코드 블록도 예외를 트리거하므로 현재 fnally 코드 블록의 실행을 중단하고 예외를 발생시켜야 합니다.
2. 예외 분류
1. 모든 예외의 상위 클래스는 Throwable입니다.
2. 오류 예외는 스레드를 종료할 수만 있는 상태입니다. 또는 JVM 예외를 종료할 수도 있습니다
3 .Exception은 Error
4보다 덜 심각한 예외입니다. Runtime Exception 및 Error는 확인할 필요가 없는 예외입니다
5. Runtime Exception 및 Error를 제외하면 예외는 Check Exception 예외입니다
6 .Check 예외 예외는 명시적이어야 합니다. 예외 발생
Java 가상 머신이 예외 인스턴스를 생성하는 데는 비용이 매우 많이 듭니다. 가상 머신은 예외의 스택 추적을 생성해야 합니다. 이 작업은 현재 스레드의 Java 스택 프레임에 하나씩 액세스하여 스택 프레임이 가리키는 메서드 이름, 메서드의 클래스 이름 및 파일 이름, 코드의 행을 포함하여 다양한 디버깅 정보를 기록합니다. 예외가 발생한 곳.
예외 인스턴스를 구성하는 데 비용이 많이 들기 때문에 예외 인스턴스를 캐시하고 필요할 때 직접 던질 수 있나요? 문법적인 관점에서는 이것이 허용됩니다. 그러나 이 예외에 해당하는 스택 추적은 throw 문의 위치가 아니라 새로운 예외의 위치입니다.
따라서 이 접근 방식은 개발자가 잘못된 위치를 타겟팅하도록 오해할 수 있습니다. 이것이 실제로 우리가 종종 새로운 예외 인스턴스를 발생시키는 것을 선택하는 이유입니다.
Exception handler
1. 출처: 각 메서드는 컴파일 시 예외 테이블을 생성합니다. 예외 테이블의 각 항목은 예외 처리기를 나타냅니다.
2. 구성:
(1) 포인터에서 포인터로: Try의 범위인 예외 포착 범위를 나타냅니다.
(2)타겟 포인터: 캐치의 시작 위치인 프로세서의 시작 위치를 나타냅니다.
(3)예외 유형이 발견되었습니다.
3. 예외 잡기
(1) 프로그램이 예외를 트리거하면 Java 가상 머신은 예외 테이블의 모든 항목을 위에서 아래로 순회합니다. 예외를 발생시키는 바이트 코드의 인덱스 값이 예외 테이블 항목의 모니터링 범위 내에 있는 경우 JVM(Java Virtual Machine)은 던져진 예외가 해당 항목이 포착하려는 예외와 일치하는지 여부를 확인합니다. 일치하는 항목이 있으면 Java Virtual Machine은 항목의 대상 포인터가 가리키는 바이트 코드로 제어 흐름을 전송합니다.
(2) 모든 예외 테이블 항목을 탐색했지만 Java 가상 머신이 여전히 예외 핸들러와 일치하지 않는 경우 현재 메소드에 해당하는 Java 스택 프레임을 팝업하고 호출자에서 위 작업을 반복합니다. 최악의 경우, JVM(Java Virtual Machine)은 현재 스레드의 Java 스택에 있는 모든 메소드의 예외 테이블을 순회해야 합니다.
4. finally 코드 컴파일: 현재 버전의 Java 컴파일러는 fnally 코드 블록의 내용을 복사하여 try-catch 코드 블록의 모든 정상 실행 경로와 비정상 실행 경로의 출구에 배치합니다.
代码1: Try{ Try block } catch { Catch block } finally { Finally block }
代码2: Try { Try block Finally block } catch { Catch block Finally block } finally{ Finally block }
Code 1은 Java 코드이고, 코드 2는 컴파일된 Java 코드입니다.참고: catch 블록이 예외를 포착하고 다른 예외를 트리거하는 경우 최종적으로 어떤 예외를 포착하고 다시 발생시키나요? 대답은 후자이다. 즉, 원래 예외가 무시되며 이는 코드 디버깅에 매우 해롭습니다.
이전 섹션에서 언급했듯이 catch 예외는 무시됩니다. Java7에서는 억제된 예외 처리 문제를 도입했습니다. 하지만 여전히 사용하기가 매우 번거롭습니다(경험이 없습니다,
위 내용은 JVM을 사용하여 Java 예외를 포착하는 방법은 무엇입니까? (예제 포함)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!