🚨 Error
Error의 하위 클래스로, Throwable 합리적인 애플리케이션에서는 포착하려고 시도해서는 안 되는 심각한 문제를 나타냅니다. 이러한 오류는 대부분 비정상적인 상태입니다.
🛠️ Exception
클래스 와 하위 클래스는 합리적인 애플리케이션이 포착하고자 할 수 있는 조건을 나타내는 Exception형식입니다.
Error Exception
Java는 애플리케이션 실행 중 발생할 수 있는 이상 상태를 두 가지 클래스로 구분합니다.
Exception: 애플리케이션이 예측하고 복구할 수 있는 문제Error: 시스템 수준 문제로, 애플리케이션이 복구할 수 없는 심각한 문제
💻 Reasonable Application
위 JavaDocs 원문을 보면 합리적인 애플리케이션이라는 문장이 공통적으로 강조되어 설명하고 있습니다.
Error는 애플리케이션이 예측하거나, 포착하려고 시도조차해서는 안되고,
반대로 Exception은 예상범위 내에서 예측하고, 포착하는 것을 합리적인 애플리케이션이라고 표현하고 있습니다.
이러한 가이드라인을 준수하는 애플리케이션을 JavaDoc에선 합리적인 애플리케이션(Reasonable Application)이라고 표현합니다.
🙌 Error를 잡지 않는 합리적인 이유
만약 여러분이 만든 애플리케이션에 OutOfMemoryError가 발생한 상황이고
애플리케이션 이것을 예측하고 포착하여 복구(Recovery)를 시도 중인 상황을 예를 들어 봅시다.
애플리케이션이 어떤 방식으로 스스로 복구 할 수 있을까요?
Error Message를 작성하여 사용자에게 알린다.
-
Memory가 없는 상태를 사용자에게 알려서 어떻게 복구하나요?
즉, 사용자는 Error Message를 받아도 애플리케이션이 스스로 복구되도록 유도 할 수 없습니다. -
Memory가 부족한 상태에서 복구를 하기위해 Error Response 객체를 만들어 복구한다?
해당 객체를 만들 메모리 조차 없을 수도 있고 무엇보다 상태를 더욱 악화시키는 방식입니다.
Error를 포착하여서 로직적으로 해결한다.
- 서버 Memory가 부족하여 생긴 Error를 포착하고 자바코드를 통해 해결 할 수 있나요?
물론, GC 튜닝을 하거나 Memory leak를 개선하는 작업을 누군가가 할 수 있지만
실행중인 애플리케이션이 스스로 해결할 수는 없습니다.
🧐 결론
따라서 Error를 예측하여도, 포착하여도, 이를 스스로 복구하려고 해도, 근본적인 문제를 해결하지 못합니다.
결국 개발자가 애플리케이션을 종료하고, Memory Leak 분석, GC튜닝, 수평/수직확장을 통해 해결해야하는
문제이지, 실행중인 애플리케이션이 스스로 복구할만한 문제가 아닙니다.
이러한 이유때문에 Java에서는 Error를 예측, 포착하려고 시도하지않고 더나아가 복구조차 하지 않는
애플리케이션을 합리적이라고 표현합니다.
