Java 런타임 오류에 대한 간략한 개요

· Java의 런타임 오류는 무엇입니까?
· 런타임 오류 VS 컴파일 시간 오류
· 런타임 오류 유형
· 런타임 오류는 어떻게 나타납니까?
· 런타임 오류를 발생시켜야 하나요
? · 런타임 예외를 포착하지 않으면 어떻게 됩니까?
· 런타임 오류 예

Java의 런타임 오류는 무엇입니까?

프로그램 실행 시 발생하는 오류를 런타임 오류라고 합니다. 이러한 유형의 오류는 구문에 문제가 없기 때문에 컴파일 시간에 감지할 수 없습니다. 따라서 런타임 오류는 프로그램이 오류를 제공하지 않고 ".class" 파일을 생성하지 않고 성공적으로 컴파일되었을 때 발생합니다. 그러나 프로그램이 제대로 실행되지 않습니다. 이러한 오류는 런타임 또는 프로그램 실행 시 감지됩니다.

Java 컴파일러에는 사용 가능한 모든 런타임 정보가 없기 때문에 이러한 오류를 포착하는 기술이 없기 때문에 Java 컴파일러는 런타임 오류를 감지하지 않습니다. 런타임 오류는 프로그램이 실행 중일 때 JVM( Java Virtual Machine ) 에 의해 포착됩니다 .

이러한 런타임 오류를 예외 라고 하며 프로그램을 비정상적으로 종료하여 오류 설명을 제공합니다.

예외는 런타임 시 발생하는 오류입니다. Java에서 예외 처리 기술을 사용하여 이러한 런타임 오류를 처리할 수 있습니다. 예외 처리에서 프로그래머가 오류를 생성할 수 있다고 생각하는 코드 조각을 try 블록 안에 넣고 프로그래머는 catch 블록 내에서 오류를 잡을 수 있습니다.

런타임 오류 VS 컴파일 시간 오류

컴파일 타임 오류는 일반적으로 의미 또는 구문에 해당하는 오류를 나타냅니다. 런타임 오류는 런타임 동안 코드 실행 중에 발생하는 오류를 말합니다 . 코드 개발 중에 컴파일 시간 오류를 쉽게 수정할 수 있습니다. 컴파일러는 런타임 오류를 식별할 수 없습니다.

발각

컴파일러는 코드 개발 중에 컴파일 타임 오류를 쉽게 감지할 수 있습니다. 컴파일러는 런타임 오류를 쉽게 감지할 수 없습니다. 따라서 코드 실행 중에 이를 식별해야 합니다.

참조

컴파일 타임 오류는 일반적으로 의미 체계 또는 구문에 해당하는 오류를 나타냅니다. 런타임 오류는 컴파일러에서 감지되지 않지만 코드 실행 중에 발생하는 오류를 나타냅니다(런타임 중).

영향

컴파일 시간 오류는 의미 체계 또는 구문 오류이며 일부 구문 오류를 감지하여 코드 실행(컴파일)을 방지합니다. Weares 런타임 오류로 인해 코드가 완전히 실행되지 않습니다.

정착

코드 개발 중에 컴파일 시간 오류를 쉽게 수정할 수 있습니다. 컴파일러는 런타임 오류를 식별할 수 없습니다. 그러나 이전에 코드를 실행하고 코드를 식별한 후에 수정할 수 있습니다.

런타임 오류 유형

프로그램 실행 시 직면할 수 있는 여러 유형의 런타임 오류가 있습니다. 자주 발생하는 일부 런타임 오류는 다음과 같습니다.

데이터 입력 오류 : 입출력 오류

사용자 입력이 응용 프로그램을 손상시킬 수 있는 방법은 무수히 많습니다.

HTML 기반 댓글 보드에서 인코딩되지 않은 보다 작음 (<) 또는 보다 큼 기호(>) 를 제출하도록 허용된 사용자는 해당 웹 페이지의 렌더링 기능을 완전히 망칠 가능성이 있습니다. 마찬가지로, ASCII 형식의 모든 입력을 기대하도록 구축된 텍스트 처리 시스템은 이모티콘이나 비표준 문자 입력을 받으면 조기에 종료될 수 있습니다.

더욱 악의적인 것은 해커들이 가장 좋아하는 공격 벡터는 SQL 삽입 으로 , 그렇지 않으면 무해한 입력 필드 안에 유해한 실행 가능한 데이터베이스 쿼리를 숨깁니다. 이로 인해 애플리케이션이 실패할 수 있을 뿐만 아니라 잠재적으로 전체 데이터 계층에 대한 제어를 포기할 수 있습니다.

입력 삭제 또는 데이터 스크러빙 프로세스는 잠재적으로 애플리케이션에 입력할 수 있는 광범위한 데이터를 프로그램이 이해할 수 있는 안전한 값 범위로 변환합니다. 이러한 라이브러리를 사용하면 입력 삭제 실패로 인한 런타임 오류를 완화하는 데 도움이 됩니다.

Apache BVal 및 Hibernate Validator와 같은 인기 있는 Java 프레임워크는 간단한 주석 기반 입력 정리를 수행하며 모든 Java 기반 애플리케이션에 쉽게 통합됩니다.

잘못 구현된 논리

코드가 컴파일된다고 해서 제대로 작동하는 것은 아닙니다. 코드에는 종종 애플리케이션이 런타임에 실패하게 만드는 논리적 문제가 포함되어 있습니다.

Java에는 RuntimeException 또는 확인되지 않은 예외라고 하는 일반적인 코드 관련 런타임 오류 클래스를 처리하기 위한 내장 구조가 포함되어 있습니다. Java 17은 SDK에서만 이러한 오류를 78개 정의하고 다른 프로젝트 및 프레임워크는 자체 RuntimeException 오류를 추가로 정의합니다.

• 런타임 예외
• ArrayIndexOutOfBoundException
• ConcurrentModificationException
• ClassCastException
• …

최소한 모든 애플리케이션에는 가능한 모든 RuntimeException을 포착하고, 오류를 기록하고, 문제가 있는 실행 스레드가 전체 애플리케이션을 중단하지 않고 중단되도록 할 수 있는 일반 예외 하네스가 포함되어야 합니다.

불충분한 런타임 리소스

소프트웨어 개발자는 발생하는 모든 유형의 런타임 오류에 대해 책임을 지지 않습니다. Java의 많은 런타임 오류에는 기본 인프라 문제로 인한 리소스 제한이 포함됩니다. 예를 들면 다음과 같습니다. 네트워크 시간 초과, 메모리 부족 상태, CPU 과잉 사용 또는 프로세서에서 스레드를 예약할 수 없음.

리소스 관련 런타임 오류를 방지하는 한 가지 방법은 애플리케이션의 CI/CD 파이프라인에서 JMeter 또는 LoadRunner와 같은 부하 테스트 도구를 사용하는 것입니다. 이러한 도구가 가능한 성능 문제를 감지하면 애플리케이션이 프로덕션 배포를 향한 파이프라인 아래로 더 이동하기 전에 애플리케이션을 중지할 수 있습니다.

일부 응용 프로그램의 부하는 크게 다릅니다. 예를 들어 금융 서비스 앱은 대부분의 시간 동안 꾸준한 로드를 볼 수 있지만 거래일이 끝날 때 매우 바쁠 수 있습니다. 세무 서비스는 제출 마감일 전에 최대 부하에 도달할 수 있지만 나머지 연도에는 상대적으로 부하가 적습니다.

DevOps 팀은 리소스 관련 런타임 오류를 선제적으로 감지하고 완화하는 도구를 사용하여 성능 메트릭을 모니터링해야 합니다. 이러한 도구의 예로는 JDK Flight Recorder 및 Java Mission Control이 있습니다 .

완전히 예측할 수 없는 워크로드가 있는 애플리케이션의 경우 클라우드 기반 로드 밸런싱 기술을 사용하여 리소스를 탄력적으로 할당합니다. 이렇게 하면 할당되지 않은 리소스와 비싸고 거의 사용되지 않는 하드웨어를 구입하는 함정이 모두 제거됩니다.

외부 리소스 구성

엔터프라이즈 애플리케이션은 고립된 버블에 거의 존재하지 않습니다. 일반적으로 NoSQL 데이터베이스 및 관계형 시스템에서 Kafka 대기열 및 RESTful API에 이르기까지 모든 것과 상호 작용합니다. 안타깝게도 응용 프로그램이 필요한 외부 시스템에 연결할 수 없는 경우 필연적으로 런타임 오류가 발생합니다.

호출 프로그램에 대한 해당 업데이트 없이 다음 상황 중 하나가 발생하는 경우 외부 리소스로 인해 런타임 오류가 발생할 수 있습니다.

• IP 주소가 변경됩니다.
• 자격 증명 변경
• 방화벽 구성 변경 또는
• 유지 보수를 위해 외부 시스템이 다운됩니다.

이와 관련하여 카오스 엔지니어링 도구는 응용 프로그램이 의존하는 프로세스를 무작위로 종료합니다. 이러한 도구를 사용하면 개발자는 외부 시스템이 실패하더라도 응답성과 탄력성을 유지하는 코드를 작성할 수 있습니다.

외부 리소스의 본질적인 문제는 개발자가 외부 리소스를 제어할 수는 없지만 이러한 외부 리소스가 실패할 때 애플리케이션이 응답하는 방식을 제어할 수 있다는 것입니다. 제어하지 않는 시스템에서 생성되는 런타임 오류를 예상하고 해당 외부 시스템이 실패할 때 적절하게 응답하는 애플리케이션을 작성합니다.

타사 라이브러리 취약점

사소하지 않은 모든 엔터프라이즈 애플리케이션에는 로깅, 모니터링, 입력 유효성 검사, 양식 처리 등과 같은 기능을 수행하기 위해 타사 라이브러리에 대한 수십 개의 종속성이 포함됩니다.

안타깝게도 타사 라이브러리의 모든 버그는 배포하는 애플리케이션의 버그가 됩니다. 널리 사용되는 Log4j 2 라이브러리의 LDAP 주입 결함으로 인해 전 세계 JVM이 오프라인 상태가 되면서 2021년 12월에 Java 세계에 불편한 현실이 되었습니다 .

소프트웨어 종속성으로 인해 애플리케이션에 런타임 오류가 발생할 가능성을 완화하는 한 가지 방법은 Apache 또는 Eclipse와 같은 조직의 신뢰할 수 있는 라이브러리만 사용하는 것입니다 .

또 다른 보호 조치는 업데이트가 제공되는 즉시 응용 프로그램의 종속성을 최신 버전으로 정기적으로 업데이트하는 것입니다.

마지막으로, 1차 종속성이 의존하는 2차 또는 3차 종속성을 인식하고 이러한 종속성이 가져오는 모든 위험을 인식하십시오.

소프트웨어 개발의 세계에서 "완벽"은 "완료"의 적입니다. 어떤 프로그램도 예상치 못한 런타임 오류의 위협으로부터 자유롭지 않습니다. 그러나 엔터프라이즈 개발자가 가능한 원인에 대한 인식을 높이고 잠재적인 위협을 완화하기 위한 조치를 취하면 런타임 오류 발생 가능성을 최소화하는 소프트웨어를 만들 수 있습니다.

런타임 오류는 어떻게 나타납니까?

축하해요! 명령 프롬프트가 다음과 같은 경우:

그런 다음 프로그램을 Java 바이트코드로 성공적으로 컴파일했습니다. 즉, 코드에 구문 문제가 없었습니다! 그러나 파일 이름에서 알 수 있듯이 이 프로그램을 실행할 때:

이제 런타임 오류가 발생했습니다. 런타임 오류는 일반적으로 코드에 논리적으로 잘못된 것이 있을 때 발생합니다. 이 문서는 런타임 오류를 읽고 수정하는 방법을 설명합니다.

런타임 오류의 주요 부분은 다음과 같습니다.

"main" 스레드의 예외 : 이 부분은 대부분의 런타임 오류에 대해 나타납니다. 항상 발생해야 하는 기본 메서드에서 예외가 발생했음을 알려줍니다.

java.lang.ArrayIndexOutOfBoundsException: 5 : 발생한 오류입니다. 오류의 이름은 일반적으로 발생한 상황에 대한 아이디어를 제공합니다. 이 경우 배열을 처리하고 배열에 할당된 공간을 벗어나는 것을 알고 있습니다.

at RunTimeErrors.main(RunTimeErrors.java:10) : 이것은 오류가 발생했을 때 실행 중인 메서드 목록을 알려주는 스택 추적이라고 합니다.

• RunTimeErrors.main은 이 오류가 RunTimeErrors 클래스의 기본 메서드 내에서 발생했음을 알려줍니다.
• RunTimeErrors.java:10은 이것이 발생한 파일과 발생한 라인을 알려줍니다. 이 경우, 이것은 메인 클래스의 10 행에서 발생했습니다 .

종종 IllegalArgumentException 으로 작업할 때 시스템이 단독으로 수행할 수 없는 경우 런타임 예외를 throw할지 여부를 결정하기 위해 확인을 수행해야 하지만 대부분의 경우 이것은 다음의 일부이기 때문에 확인을 수행할 필요가 없습니다. Java가 수행하는 표준 런타임 검사.

NullPointerException을 예로 들어 보겠습니다 .

if(t == null) 
 throw new NullPointerException();

if(t != null) {
  // work with t reference
}

런타임 예외를 포착하지 않으면 어떻게 됩니까? 컴파일러가 이에 대한 예외 사양을 적용하지 않기 때문에 RuntimeException이 잡히지 않고 main( ) 메서드로 스며들 수 있다는 것은 꽤 그럴듯합니다. 이 경우 어떤 일이 발생하는지 확인하려면 다음 예제를 시도하십시오.

//: exceptions/NeverCaught.java 
// Ignoring RuntimeExceptions. 
// {ThrowsException} 
public class NeverCaught { 
 static void f() { 
 throw new RuntimeException("From f()"); 
 } 
 static void g() { 
 f(); 
 } 
 public static void main(String[] args) { 
 g(); 
 } 
} ///:~

Exception in thread "main" Java.lang.RuntimeException: From f() 
    at NeverCaught.f(NeverCaught.Java:7) 
    at NeverCaught.g(NeverCaught.Java:10) 
    at NeverCaught.main(NeverCaught.Java:13)

컴파일러가 확인된 모든 예외를 신중하게 처리하기 때문에 RuntimeException (및 하위 클래스) 유형의 예외만 코딩에서 무시할 수 있음을 명심하십시오 . 그 이유는 RuntimeException 이 다음과 같은 프로그래밍 오류를 나타내기 때문입니다.

예상할 수 없는 오류입니다. 예를 들어 제어할 수 없는 null 참조입니다.

프로그래머로서 코드에서 확인했어야 하는 오류(예: 배열 크기에 주의를 기울여야 하는 ArraylndexOutOfBoundsException ). 포인트 #1에서 발생하는 예외는 종종 포인트의 문제가 됩니다.

이 경우 디버깅 프로세스에 도움이 되는 예외가 있다는 것이 얼마나 큰 이점인지 알 수 있습니다.

Java 예외 처리를 단일 목적 도구로 분류할 수 없다는 사실이 흥미롭습니다. 예, 코드의 제어를 벗어난 힘으로 인해 발생하는 성가신 런타임 오류를 처리하도록 설계되었지만 컴파일러가 감지할 수 없는 특정 유형의 프로그래밍 버그에도 필수적입니다.

런타임 오류 예

public class Temp {
public static void main(String[] args) {
  Temp t = initT();
  
  t.foo("Hi");
  
 }
 private static Temp initT() {
  return null;
 }
 public void foo(String s) {
  System.out.println(s.toLowerCase());
 }
}

Exception in thread "main" java.lang.NullPointerException
	at Temp.main(Temp.java:7)

이 범주에 속하는 전체 예외 유형 그룹이 있습니다. 항상 Java에 의해 자동으로 발생하므로 예외 사양에 포함할 필요가 없습니다. 편리하게도, 상속의 완벽한 예인 RuntimeException 이라는 단일 기본 클래스 아래에 배치하여 모두 함께 그룹화합니다 . 몇 가지 공통된 특성과 동작이 있는 유형 패밀리를 설정합니다. 또한 확인되지 않은 예외이기 때문에 메소드가 RuntimeException (또는 RuntimeException 에서 상속된 모든 유형 )을 던질 수 있다고 말하는 예외 사양을 작성할 필요가 없습니다. 버그를 나타내기 때문에 일반적으로 RuntimeException을 포착하지 않습니다.— 자동으로 처리됩니다. RuntimeExceptions 를 확인해야 하는 경우 코드가 너무 지저분해질 수 있습니다. 일반적으로 RuntimeExceptions 를 포착하지 않더라도 자체 패키지에서 일부 RuntimeExceptions 를 발생시키도록 선택할 수 있습니다 .

가장 일반적인 런타임 예외 보기

즐거운 배움

Mouad Oumous Java WhatsApp 그룹에 가입하세요 .

Mouad Oumous 텔레그램 채널 가입 JOIN

그것을 따라 우리 출판물을 지원하십시오

GraphQL with Spring Boot The Most Common Java Runtime Errors Getting Started with Spring Boot: A Comprehensive Tutorial for Beginners 삶의 질을 향상시키는 간단하지만 효과적인 10가지 방법 가장 자주 묻는 Java8 스트림 기반 인터뷰 질문 — 마지막 파트 I 책을 써서 $300 벌기 2일 만에 — Java에서 예외 체인이 무엇인지는 다음과 같습니다 . | 예외 처리 데이터베이스 통합으로 간단한 Quarkus 프로젝트를 생성하는 방법