이 기사는 Java의 예외 메커니즘 개념에 중점을 둡니다. 이 기사를 작성하는 목적은 오랜 시간이 지난 후에 이러한 것들을 기억하도록 촉진하는 것입니다.
1. 예외 메커니즘
1.1 예외 메커니즘은 오류가 발생할 때 프로그램이 처리하는 방법을 나타냅니다. 구체적으로, 예외 메커니즘은 프로그램 종료를위한 안전한 채널을 제공합니다. 오류가 발생하면 프로그램 실행 프로세스가 변경되고 프로그램 제어가 예외 프로세서로 전송됩니다.
1.2 예외를 다루는 전통적인 방법은 함수가 예외가 발생 함을 나타내는 특수 결과를 반환한다는 것입니다 (일반적 으로이 특별한 결과는 일반적으로 그대로 알려져 있음). 예를 들어, 함수가 -1을 반환하면 예외가 발생한다는 것을 의미하지만 함수가 올바른 값 -1을 반환하려면 혼동됩니다. 가독성이 줄어들고 프로그램 코드는 예외를 처리하는 코드와 혼합됩니다. 기능을 호출하는 프로그램은 오류를 분석하여 클라이언트 프로그래머가 라이브러리 기능을 깊이 이해해야합니다.
1.3 예외 처리 프로세스
1.3.1 오류가 발생하면 메소드가 즉시 끝나고 값을 반환하지 않습니다. 동시에, 예외 객체가 던져집니다.
1.3.2이 방법을 호출하는 프로그램은 계속 실행되지 않지만 예외를 처리하고 코드를 실행할 수있는 예외 핸들러를 검색합니다.
2 예외 분류
2.1 예외 분류
2.1.1 예외의 상속 구조 : 기본 클래스는 던질 가능, 오류 및 예외는 던질 가능, runtimeexception 및 ioexception 등을 상속 받고 특정 runtimeexception은 runtimeexception을 상속합니다.
2.1.2 오류 및 runtimeexception 및 하위 클래스는 확인되지 않은 예외가되고 다른 예외는 점검됩니다.
2.2 각 유형의 예외의 특성
2.2.1 오류 시스템 오류 클래스 시스템은 Java 운영 체제의 내부 오류 및 리소스 소진을 설명합니다. 응용 프로그램은이 유형의 객체를 던지지 않아야합니다 (일반적으로 가상 기계에 의해 던져짐). 그러한 오류가 발생하면 프로그램을 안전하게 종료하려고 시도하는 것 외에는 할 수있는 다른 것이 없습니다. 따라서 프로그래밍을 설계 할 때는 예외 시스템에 더 많은주의를 기울여야합니다.
2.2.2 예외 시스템 예외 시스템에는 runtimeexception 시스템 및 기타 비 unruntimeexception 시스템이 포함됩니다.
2.2.2.1 runtimeexception runtimeexception 시스템에는 잘못된 유형 변환, 배열 외 액세스, 널 포인터에 액세스하려는 시도 등이 포함됩니다. runtimeexception을 처리하는 원리는 다음과 같습니다. 예를 들어, 배열 외부 액세스 예외는 배열 첨자 및 배열 경계를 확인하면 피할 수 있습니다.
2.2.2.
2.3 C ++ 예외 분류의 차이점
2.3.1 실제로 런타임에 예외가 발생하기 때문에 Java의 Runtimeexception 클래스 이름은 적절하지 않습니다. (컴파일 중에 발생하는 오류는 예외가 아닙니다. 즉, 예외는 프로그램 실행 중에 발생하는 오류를 해결하는 것입니다).
2.3.2 C ++의 Logic_Error는 Java의 runtimeexception과 동일하지만 runtime_error는 Java의 비-unruntimeexception 유형의 예외와 동일합니다.
3. 예외를 사용하는 방법
3.1 선언 방법은 예외를 던집니다
3.1.1 구문 : 던지기 (생략)
3.1.2 예외를 던지기위한 방법을 선언 해야하는 이유는 무엇입니까? 메소드가 예외를 던지는 지 여부는 메소드의 리턴 값 유형만큼 중요합니다. 이 메소드가 예외가 발생한다고 가정하면이 메소드가 예외를 던지겠다고 선언하지 않으면 클라이언트 프로그래머는 예외를 처리하기 위해 코드를 작성하지 않고이 메소드를 호출 할 수 있습니다. 그런 다음 예외가 발생하면이 예외를 해결하기위한 적절한 예외 컨트롤러가 없습니다.
3.1.3 예외가 반드시 점검 된 예외 인 이유는 무엇입니까? Runtimeexception 및 오류는 모든 코드에서 생성 될 수 있습니다. 그들은 프로그래머가 던질 필요가 없습니다. 오류가 발생하면 해당 예외가 자동으로 던져집니다. 점검 된 예외는 프로그래머가 던져지며, 이는 두 가지 상황으로 나뉩니다. 클라이언트 프로그래머는 예외를 던지는 라이브러리 기능을 호출합니다 (라이브러리 기능의 제외는 라이브러리 프로그래머가 던져집니다). 클라이언트 프로그래머는 Throw 문을 사용하여 스스로 예외를 던졌습니다. 오류가 발생할 때 프로그래머는 일반적으로 힘이 없습니다. runtimeexception을 만나면 프로그램에 논리적 오류가 있어야하며 프로그램을 수정해야합니다 (디버깅 방법과 동일). 점검 된 예외만으로는 프로그래머가 관심을 갖는 것이며, 프로그램은 확인 된 예외 만 던지거나 처리해야합니다.
3.1.4 참고 : 부모 클래스의 특정 방법을 다루는 서브 클래스 방법은 상위 클래스 방법보다 더 많은 예외를 던질 수 없습니다. 따라서 때로는 상위 클래스 메소드를 설계 할 때 예외가 제외되지만 메소드를 구현하기위한 실제 코드는 예외를 제외하지 않습니다. 이것의 목적은 서브 클래스 메소드가 부모 클래스 메소드를 덮어 쓰는 것을 용이하게하는 것입니다.
3.2 예외를 던지는 방법
3.2.1 구문 : 던지기 (생략)
3.2.2 어떤 예외가 발생합니까? 예외 객체의 경우 객체 유형은 예외가 객체 유형 일 때 실제로 유용하며 예외 객체 자체는 의미가 없습니다. 예를 들어, 예외 객체 유형이 classcastException 인 경우이 클래스 이름이 유일한 유용한 정보입니다. 따라서 던질 예외를 선택할 때 가장 중요한 것은 예외 상황을 명확하게 설명 할 수있는 예외의 클래스 이름을 선택하는 것입니다.
3.2.3 일반적으로 예외 객체에 대한 두 개의 생성자가 있습니다. 하나는 매개 변수가없는 생성자입니다. 다른 하나는 문자열이있는 생성자이며, 유형 이름 외에이 예외 객체에 대한 추가 설명으로 사용됩니다.
3.2.4 자신만의 예외 생성 : Java의 내장 예외가 예외 상황을 명확하게 설명 할 수없는 경우 자신의 예외를 만들 필요가 있습니다. 유일한 유용한 것은 유형 이름 정보이므로 예외 클래스의 설계에 에너지를 소비하지 마십시오.
3.3 예외를 캡처하여 예외가 처리되지 않은 경우, 비 그래픽 인터페이스 프로그램의 경우 프로그램이 중단되고 예외 정보를 출력합니다. 그래픽 인터페이스 프로그램의 경우 예외 정보도 출력되지만 프로그램은 중단되지 않지만 사용자 인터페이스 처리 루프로 돌아갑니다.
3.3.1 구문 : 시도, 캐치 및 마침내 (생략) 컨트롤러 모듈은 시도 블록 바로 뒤에 있어야합니다. 예외가 발생하면 예외 제어 메커니즘은 매개 변수가 예외 유형과 일치하는 첫 번째 컨트롤러를 검색 한 다음 Catch 절을 입력하고 예외가 제어되었다고 생각합니다. 캐치 절이 완료되면 컨트롤러 검색도 중지됩니다.
3.3.1.1 여러 예외를 포착합니다 (구문 및 캡처 순서에 유의) (생략)
3.3.1.2 사용 및 예외 처리 프로세스 최종적으로 (생략)
3.3.2 예외 처리는 무엇을합니까? Java의 경우 쓰레기 수집으로 인해 예외 처리에는 메모리 재활용이 필요하지 않습니다. 그러나 파일, 네트워크 연결 및 사진과 같이 프로그래머가 수집 해야하는 리소스가 여전히 있습니다.
3.3.3 메소드가 예외를 던지거나 방법에서 예외를 포착해야합니까? 원칙 : 처리 방법을 알고있는 예외를 잡고 처리하고 처리 방법을 모르는 예외를 통과합니다.
3.3.4 예외를 다시 던지십시오
3.3.4.1 왜 예외를 다시 던지는가? 이 수준에서는 컨텐츠의 일부만 처리 할 수 있으며 일부 처리는 더 높은 수준의 환경에서 완료해야하므로 예외를 다시 던져야합니다. 이를 통해 각 예외 핸들러가 처리 할 수있는 예외를 처리 할 수 있습니다.
3.3.4.2 동일한 시도 블록에 해당하는 캐치 블록은 무시되며, 던진 예외는 더 높은 레벨로 들어갑니다.
4 예외에 관한 다른 질문
4. 이것은 잘못되었습니다. 완전히 알려진 오류의 경우 프로그램의 견고성을 높이기 위해 이러한 오류를 처리하는 코드를 작성해야합니다. 또한 비정상 메커니즘의 효율은 매우 열악합니다.
4.2 예외를 일반적인 오류로부터 나누는 것. 일반적인 오류의 경우 프로그램의 견고성을 높이기 위해 이러한 오류를 처리하는 코드를 작성해야합니다. 예외는 외부 결정 불가능하고 예측 된 런타임 오류에 대해서만 필요합니다.
4.3 예외 객체에 포함 된 정보는 일반적으로 말하면, 예외 객체에 대한 유일한 유용한 정보는 유형 정보입니다. 그러나 예외 문자열 생성기를 사용하면이 문자열을 추가 정보로 사용할 수도 있습니다. getMessage (), toString () 또는 printStackTrace ()를 호출하여 예외 객체의 메소드는 각각 추가 정보, 클래스 이름 및 통화 스택 정보를 얻을 수 있습니다. 후자에는 전자의 슈퍼 세트 인 정보가 포함되어 있습니다.
일반적으로 사용되는 예외 :
UnsupportedOperationException에서 지원하지 않는 작업
불법적 인 매개 변수
indexoutofBoundSexection 인덱스 아웃 바운드
불법 상태 불법 국가
비정상적인 경고와 평범한 경고 사이에는 특정한 차이가 있습니다. 응용 프로그램에서 예외가 발생하면 실행 프로그램의 정상적인 흐름이 중단됩니다. 즉, 예외가 발생한 후 코드는 올바르게 실행되지 않습니다. 데이터베이스 롤백 작업도 트리거합니다.
Java Development Platform에서 예외에는 사전 정의 된 예외 및 사용자 정의 예외가 포함됩니다. 이 두 가지 유형의 예외는 서로를 보완합니다. 자격을 갖춘 프로그램 개발자로서 응용 프로그램에서 예외를 사용하는 데 능숙합니다. 이것은 응용 프로그램의 상호 작용을 향상시킬 수 있습니다. 동시에, 그것은 또한 응용 프로그램의 정상적인 작동을 보장하기위한 전제 조건입니다. 따라서 예외 처리는 우수한 응용 프로그램을 개발하는 데 매우 중요합니다. 이러한 이유로 저자는 프로그램 개발자가 Java 응용 프로그램의 일반적인 예외를 심도있게 이해해야한다고 생각합니다. 이러한 일반적인 예외를 이해할 때만 사용자 정의 예외를 잘 처리 할 수 있습니다.
1. 일반적인 예외의 유형과 원인.
Java 응용 프로그램의 일반적인 예외와 관련하여 저자는 프로그램 개발자가 두 가지 측면에서이를 이해해야한다고 생각합니다. 첫째, 공통 Java 응용 프로그램 예외가 무엇인지 알아야하며, 둘째,이 예외가 발생할 수있는 원인을 알아야합니다. 이를 위해서는 프로그램 관리자가 일상 업무에서 축적에주의를 기울여야 할뿐만 아니라 필요한 경우 다른 채널에서 정보를 수집해야합니다. 저자는 모든 프로그램 개발자에게 도움이되기를 희망하면서 이에 대한 분석을 수행 할 것입니다.
1. sqlexection : 데이터베이스 예외 클래스를 작동합니다.
오늘날의 Java 응용 프로그램의 대부분은 실행할 데이터베이스에 의존합니다. Java 응용 프로그램이 데이터베이스와 통신 할 때 오류가 발생하면이 클래스가 트리거됩니다. 동시에 데이터베이스 오류 정보는이 클래스를 통해 사용자에게 표시됩니다. 다시 말해,이 작동 데이터베이스 예외 클래스는 데이터베이스와 사용자 간의 예외 정보 전송을위한 브리지입니다. 예를 들어, 사용자는 이제 시스템에 데이터를 삽입하고 특정 필드가 데이터베이스에서 고유해야한다고 규정합니다. 사용자가 데이터를 삽입하면이 필드의 값이 기존 레코드로 반복되면 데이터베이스의 고유성 제약 조건을 위반하고 예외 메시지가 데이터베이스에서 해제됩니다. 이 정보는 데이터베이스 수준에서 발생하기 때문에 사용자에게 보이지 않을 수 있습니다. 현재이 작업 데이터베이스 예외 클래스는 데이터베이스 예외 정보를 캡처하고 예외 정보를 전경으로 전달합니다. 이러한 방식으로 프론트 데스크 사용자는이 예외 정보를 기반으로 오류의 원인을 분석 할 수 있습니다. 이것은이 운영 데이터베이스 예외 클래스의 주요 목적입니다. Java 응용 프로그램에서는 모든 데이터베이스 작업이 예외가 발생할 때이 클래스가 트리거됩니다. Java 애플리케이션 자체의 모든 신속한 정보는 현재 너무 일반적입니다. 데이터베이스와의 상호 작용에 오류가 있고 참조 값이 많지 않다고 말합니다. 현재 데이터베이스 프롬프트 정보가 더 가치가 있습니다.
2. ClassCastException : 데이터 유형 변환 예외.
Java 응용 프로그램에서는 때때로 데이터 유형을 변환해야합니다. 이 전환에는 표시된 전환 및 암시 적 변환이 포함됩니다. 그러나 어떻게 변환하든 전제 조건, 즉 데이터 유형의 호환성을 충족해야합니다. 데이터 변환 프로세스 중에이 원칙이 위반되면 데이터 유형 변환 예외가 트리거됩니다. 예를 들어, 응용 프로그램에서 개발자는 문자 유형 날짜 데이터를 데이터베이스에서 수락 할 수있는 날짜 유형 데이터로 변환해야합니다. 이 시점에서는 전경 응용 프로그램에서만 통제하면되며 일반적으로 문제가 없습니다. 그러나 전경 응용 프로그램에 관련 제어가 부족한 경우 사용자는 날짜를 입력 할 때만 월 및 일 정보 만 입력하지만 연도 정보가 없습니다. 현재 응용 프로그램이 데이터 유형 변환을 수행하면 예외가 나타납니다. 내 경험에 따르면, 데이터 유형 변환 예외는 애플리케이션 개발에서 더 많은 예외가 발생하며 상대적으로 낮은 수준의 예외입니다. 대부분의 경우, 일부 데이터 유형에 대한 강제 제어는 응용 프로그램 창에서 수행 할 수 있기 때문입니다. 즉, 데이터 유형이 변환되기 전에 데이터 유형의 호환성이 보장됩니다. 이 경우 데이터 유형 변환 예외를 유발하기는 쉽지 않습니다. 숫자 유형 만 허용하는 필드에서 입력 할 수없는 숫자 값 이외의 문자를 설정할 수 있습니다. 예외 처리 메커니즘을 사용하면 응용 프로그램이 잘못 실행되지 않습니다. 그러나 실제 발전에서 우리는 여전히 가능한 한 오류의 원인을 예견하고 이상을 피하려고 노력해야합니다.
3. NumberformateXception : 문자열이 숫자 유형으로 변환 될 때 예외가 발생합니다.
데이터 유형 변환 프로세스 중에, 숫자 변환으로 문자 변환 과정에서 발생하는 문제 인 경우, Java 프로그램, 즉 NumberformateXception에서 독립적 인 예외가 사용됩니다. 예를 들어, 문자 유형 데이터 "123456"이 수치 데이터로 변환되면 허용됩니다. 그러나 문자 유형 데이터에 123#56과 같은 숫자가 아닌 문자가 포함 된 경우 숫자 유형으로 변환 될 때 예외가 나타납니다. 시스템은이 예외를 포착하고 처리합니다.
Java 응용 프로그램에는 많은 일반적인 예외 클래스가 있습니다. 해당 클래스 예외를 찾을 수없는 경우 일부 클래스 예외는 액세스 할 수 없으며 파일은 예외를 종료했으며 파일은 예외를 찾지 못했고 필드는 예외를 찾지 못했습니다. 일반적으로 시스템 개발자는이 예외 이름을 기반으로 현재 예외 유형을 판단 할 수 있습니다. 좋지만 좋은 기억은 나쁜 펜만큼 좋지 않습니다. 필요한 경우 (특히 사용자 정의 예외가있을 때) 프로그램 개발자는 마침내 예외 목록을 가지고 있습니다. 이 경우 응용 프로그램이 디버깅 중 문제를 발견하든 작동 중에 사용자로부터 불만을 수신하든 예외 이름을 기준으로 예외의 원인을 찾을 수 있습니다. 이를 통해 예외는 가장 짧은 시간에 해결되고 응용 프로그램의 정상 작동을 복원 할 수 있습니다. 이 측정은 수년 동안 사용되어 왔으며 매우 효과적입니다.
2. 예외 관리에 대한 실질적인 제안.
데이터베이스 예외 작동의 경우 Java 응용 프로그램은 하나의 예외 클래스 만 제공합니다. 따라서 Java 응용 프로그램의 오류 정보에만 의존하면 종종 신청자가 오류의 원인을 제거하는 데 도움이 될 수 없습니다. 이 예외가 응용 프로그램 오류 또는 데이터베이스 오류로 인해 발생하는지 여부 만 지정할 수 있습니다. 문제의 원인을 추가로 지정하기 위해 데이터베이스 수준에서 예외를 정의 할 때 특정 원인을 설명하는 것이 가장 좋습니다. 예를 들어, 전경 응용 프로그램은 데이터베이스 기능 또는 절차를 호출 할 수 있습니다. 현재 데이터베이스 기능 또는 프로세스에서 잘 수행하면 특정 예외의 특정 원인을 설명 할 수 있습니다. 예를 들어, 특정 기본 테이블을 기반으로 다른 테이블을 생성 할 때 특정 필드가 비어있을 수 없습니다. 이러한 예외 정보를 명확하게 설명한 후 실제로 유사한 예외를 발견하면 데이터베이스 예외 클래스를 작동하면 데이터베이스 예외 정보를 프론트 엔드 사용자에게 바꿉니다. 이렇게하면 사용자가 문제의 원인을 찾아 가장 짧은 시간에 수정하는 데 도움이됩니다. 물론 이것은 Java 프로그래머와 데이터베이스 디자이너 간의 조정이 필요합니다.
둘째, 예외는 표준이 아니라는 점에 유의해야합니다. 다시 말해, 대부분의 이상은 합리적인 예측과 전제 예방을 통해 제거 될 수 있습니다. 4 점 작업으로 설계된 경우 전경 응용 프로그램 창의 외과 필드에 0 값을 입력하여 응용 프로그램 작업 중에 가능한 예외를 제거 할 수 있습니다. 그러나이를 위해서는 종종 응용 프로그램 개발자에게 풍부한 업무 경험이 있고 엄격한 사고 논리가 있어야합니다. 이것이 어렵지만 저자는 사용자가 사용자가 응용 프로그램에서 디자인 버그를 발견 할 수 있도록 항상 사용자가 평가자로서 사용자를 허용하는 것이 아니라 프로그램 개발자가 여전히 열심히 노력해야한다고 생각합니다. 저자는 실제로 프로그래머를 통제 할 수없는 일부 요소 일 때만 예외가 발생할 수 있다고 생각합니다. 애플리케이션 개발자 가이 오류를 알 수 있지만 여전히주의를 기울이지 않거나 이러한 이상을 방지하기 위해 효과적인 조치를 취하지 않으면 저자가 허용하지 않습니다.
Arithmeticexception (Divisor 0의 예외), BufferoverFlowException (버퍼 오버 플로우 예외), BufferunderFlowException (버퍼 언더 플로 예외), IndexOutoFBoundSexception (아웃 바운드 예외), NullPointerException (NullPointerException), EmplePoinTackeception (빈 스택 예외), EllegalAgmentException (EllegalPormeterEction), Negativearraysizeexception, NosuchelementException, SecurityException, SystemException, 비정형 적사 가능 외출
1. java.lang.nullpointerexception
예외에 대한 설명은 "프로그램이 널 포인터를 만나게됩니다"입니다. 간단히 말해서, 그것은 존재하지 않는 객체 또는 존재하지 않는 객체, 즉 배열의 초기화를 배열 요소의 초기화와 혼동하는 것을 의미합니다. 배열의 초기화는 필요한 공간을 배열에 할당하는 것입니다. 초기화 된 배열의 요소는 인스턴스화되지 않고 여전히 비어 있으므로 각 요소가 초기화되어야합니다 (호출하려는 경우)
2. java.lang.classnotfoundException
예외에 대한 설명은 "지정된 클래스가 존재하지 않습니다"입니다.
3. java.lang.arithmeticexception
이 예외에 대한 설명은 "수학적 작업 예외"입니다. 예를 들어, 0으로 나누는 것과 같은 작업이 프로그램에 나타나면 예외가 발생합니다.
4. java.lang.arrayindexoutofboundsexception
예외에 대한 설명은 "배열 위트 스크립트가 끝났습니다"입니다. 대부분의 프로그램은 이제 배열에 대한 작업이 있습니다. 따라서 배열을 호출 할 때 호출하는 위자가 배열 범위를 초과하는지주의 깊게 확인해야합니다. 일반적으로 말하면, 호출 (즉, 상수에 직접 상수를 사용하는) 호출을 통해 그러한 실수를하기는 쉽지 않지만, 암시 적 (즉, 변수를 사용하여 첨자를 나타내는)은 종종 실수를 저지른다. 프로그램에 정의 된 배열의 길이가 특정 특정 방법에 의해 결정되고 미리 선언되지 않는 또 다른 상황이 있습니다. 현재이 예외를 피하기 위해 배열의 길이를 먼저 확인하는 것이 가장 좋습니다.
5. java.lang.illegalargumentexception
이 예외의 설명은 메소드 G.SetColor (int red, int green, int blue)의 세 가지 값과 같은 "메소드의 매개 변수 오류"입니다. 255 이상이 있으면이 예외도 발생합니다. 따라서이 예외가 발견되면 우리가해야 할 일은 메소드 호출에 전달되는 매개 변수에 오류가 있는지 신속하게 확인하는 것입니다.
6. java.lang.ilegalaccessexception
이 예외에 대한 설명은 "액세스 권한 없음"입니다. 이 예외는 응용 프로그램이 클래스를 호출하려는 경우 발생하지만 현재 방법에는 클래스에 대한 액세스 권한이 없습니다. 프로그램에서 패키지를 사용할 때는이 예외, 예외 및 Java에주의를 기울여야합니다.
읽어 주셔서 감사합니다. 도움이되기를 바랍니다. 이 사이트를 지원 해주셔서 감사합니다!