벌레
어떤 이유로든 실행 중에 프로그램이 오작동하거나 비정상적으로 종료될 수 있습니다.
이 결과를 초래하는 원인을 프로그램 버그 또는 오류라고 합니다.
발생시기에 따라 세분할 수 있습니다.
- 컴파일 오류: 컴파일하는 동안 오류가 발생했습니다.
- 런타임 오류: 프로그램 실행 중에 발생하는 오류입니다.
- 논리적 오류: 정상적으로 컴파일되고 실행되지만 의도한 것과 다르게 동작하는 오류입니다.
런타임 에러
Java에는 실행 중에 발생할 수 있는 두 가지 유형의 프로그램 오류가 있습니다.
- 실수
- 발생 후 수정할 수 없는 OutOfMemoryErrorr 또는 StackOverFlow와 같은 치명적인 오류.
- 프로그램 코드로 수정할 수 없는 치명적인 오류
- 이 경우 프로그램이 비정상적으로 종료되는 것을 방지할 수 없습니다.
- 예외
- 발생 시 수정할 수 있는 상대적으로 덜 심각한 버그
- 프로그램 코드로 수정할 수 있는 사소한 버그
- 프로그램의 비정상 종료를 방지할 수 있습니다.
예외 클래스 계층
Java에서는 실행 중 발생할 수 있는 오류(Exception 및 Error)를 클래스로 정의합니다.
- 개체: 예외도 개체입니다.
예외의 최상위 부모도 개체입니다. - Throwable: 이것은 최상위 예외입니다.
- 오류: 응용 프로그램에서 복구할 수 없는 시스템 예외입니다.
B. 메모리 부족 또는 치명적인 시스템 오류.- 응용 프로그램 개발자는 이 예외를 포착하려고 시도해서는 안 됩니다.
- 상위 예외를 포착하면 하위 예외도 포착됩니다.
- 따라서 Throwable 예외도 catch하면 안 됩니다.
- 이러한 이유로 애플리케이션 로직은 Exception을 필요한 예외로 간주하고 catch할 수 있습니다.
- 오류는 UnCheck 예외이기도 합니다.
- 응용 프로그램 개발자는 이 예외를 포착하려고 시도해서는 안 됩니다.
- 예외: 예외 확인
- 애플리케이션 논리에서 사용할 수 있는 편리한 최상위 예외입니다.
- 예외 및 모든 하위 예외 컴파일러 확인확인 예외입니다.
- 그러나 RuntimeException은 예외입니다.
- 애플리케이션 논리에서 사용할 수 있는 편리한 최상위 예외입니다.
- RuntimeException: UnCheck 예외, 런타임 예외
- 컴파일러가 확인하지 않는 것은 UncheckException입니다.
- 모든 자식 예외도 UnCheck 예외입니다.
- 하위 예외에 대한 RuntimeException의 이름을 따르십시오. 런타임 예외많이 불렀다
- 컴파일러가 확인하지 않는 것은 UncheckException입니다.
예외에 대한 2가지 기본 규칙
- 예외는 잡아서 처리하거나( try – catch ) 던져야 합니다.
(던지기) - 예외가 포착되거나 발생하면 지정된 예외뿐만 아니라 그 자식도 처리됩니다.
예외를 처리하지 않고 계속 발생하면 어떻게 됩니까?
- Java main() 스레드의 경우
- 예외 로그가 인쇄되는 동안 시스템이 종료됩니다.
- 예외 로그가 인쇄되는 동안 시스템이 종료됩니다.
- 웹 애플리케이션용
- 여러 사용자의 요청을 처리하기 때문에 단일 예외로 인해 시스템이 종료되어서는 안 됩니다.
- WAS는 예외를 수신하고 처리합니다.
- 일반적으로 개발자가 지정한 오류 페이지를 사용자에게 보여줍니다.
- 여러 사용자의 요청을 처리하기 때문에 단일 예외로 인해 시스템이 종료되어서는 안 됩니다.
확인된 예외
확인된 예외는 포착 및 처리되거나 폐기된 것으로 선언되어야 합니다.
그렇지 않으면 컴파일 오류가 발생합니다.
- 예외를 상속받아 사용하면 체크 예외가 됩니다.
- RuntimeException을 상속하면 unchecked 예외가 됩니다.
- 오류 메시지를 보관하는 기능을 포함하여 예외에서 제공하는 몇 가지 기본 기능이 있습니다.
- Check Exception은 catch 및 처리할 수 없는 경우 예외를 throw하는 throws 예외를 선언해야 합니다.
그렇지 않으면 컴파일 오류가 발생합니다. - 장점
- 개발자가 실수로 예외를 놓치는 것을 방지하기 위해 컴파일러 문제를 포착하는 훌륭한 장애 조치오전.
- 불리
- 그러나 실제로는 개발자가 모든 확인된 예외를 catch하거나 throw해야 하므로 너무 번거롭습니다.
- 너무 걱정하고 싶지 않은 예외를 포착해야 합니다.
- 종속성에는 단점이 있습니다.
- 그러나 실제로는 개발자가 모든 확인된 예외를 catch하거나 throw해야 하므로 너무 번거롭습니다.
확인되지 않은 예외
이것은 컴파일러가 예외를 확인하지 않는다는 것을 의미합니다.
- RuntimeException 및 그 하위 예외는 확인되지 않은 예외로 분류됩니다.
- 예외가 포착되어 처리되지 않더라도 예외를 선언하지 않고 throw를 생략할 수 있습니다.
이 경우 자동으로 예외가 발생합니다. - 장점
- 처리하고 싶지 않은 확인되지 않은 예외는 무시할 수 있습니다.
- 신경 쓰지 않으려는 예외 종속성을 참조할 필요가 없습니다.
- 처리하고 싶지 않은 확인되지 않은 예외는 무시할 수 있습니다.
- 불리
- 확인되지 않은 예외로 인해 개발자는 실수로 예외를 간과할 수 있습니다.
- 확인되지 않은 예외로 인해 개발자는 실수로 예외를 간과할 수 있습니다.
예외의 스택 추적
log.info("예외 처리, message = {}", e.getMessage(), e);
- 위와 같이 로그를 남기면 예외에 대한 스택 추적도 두 번째 줄에 출력됩니다.
- 프로토콜을 종료할 때 예외 개체가 프로토콜의 마지막 인수로 전달되면 프로토콜은 예외의 스택 추적도 인쇄합니다.
예외 처리
- catch는 유형과 하위 유형을 모두 잡을 수 있습니다.
- method()는 확인된 예외를 처리할 수 없는 경우 throw합니다.
예외 throw할 예외가 필수임을 나타내야 합니다.
- throws를 지정하지 않으면 컴파일 오류가 발생합니다.
- throws를 지정하지 않으면 컴파일 오류가 발생합니다.
- throws 및 해당 하위 유형에 지정된 유형의 예외를 발생시킵니다.
소환