Java에서 StackOverflowError를 잡아도 괜찮습니까?

나는 그것이 아니라고 생각했지만 어제 나는 그것을해야했습니다. Akka (JVM의 액터 시스템 구현)를 사용하여 비동기 작업을 처리 하는 응용 프로그램입니다 . 배우 중 한 명이 PDF 조작을 수행하고 라이브러리가 버그이기 때문에 가끔씩 죽습니다 StackOverflowError.

두 번째 측면은 Akka가 JVM 치명적 오류 (예 : StackOverflowError)가 발견되면 전체 액터 시스템을 종료하도록 구성되어 있다는 것입니다.

세 번째 측면은이 액터 시스템이 웹 앱 내에 내장되어 (WTF- 레거시, 레거시, 이유) 액터 시스템이 종료 될 때 웹 앱은 그렇지 않다는 것입니다. 결과적으로 StackOverflowError작업 처리 응용 프로그램에서 빈 웹 응용 프로그램이됩니다.

빠른 수정으로 StackOverflowError액터 시스템의 스레드 풀이 끊어지지 않도록 던져지는 것을 잡아야 했습니다. 이것은 아마도 이런 상황에서 특히 그러한 오류를 잡는 것이 때때로 괜찮을 것이라고 생각하게합니다. 임의의 작업을 처리하는 스레드 풀이있는 경우 달리 응용 프로그램이 일관성이없는 상태를 유지할 수있는 OutOfMemoryError방법을 상상할 수 없습니다 StackOverflowError. 이러한 오류 후에 스택이 지워 지므로 계산이 정상적으로 진행될 수 있습니다. 그러나 아마도 중요한 것이 빠져있을 것입니다.

또한, 나는 처음에 오류를 고치기위한 모든 것입니다 (사실 며칠 전에이 동일한 응용 프로그램에서 SOE를 이미 수정했습니다). 그러나 이것이 언제인지는 정말로 알지 못합니다. 상황이 발생할 수 있습니다.

를 잡는 대신 JVM 프로세스를 다시 시작하고 StackOverflowError해당 작업을 실패한 것으로 표시 한 다음 내 비즈니스를 계속 하는 것이 더 좋은 이유는 무엇 입니까?

공기업을 절대로 사로 잡을만한 이유가 있습니까? 나에게 아무 것도 알려주지 않는 모호한 용어 인 "모범 사례"를 제외하고.

일반적으로 어떤 일을하는 것이 절대로 결코 받아 들여지지 않았고 그것에 대해 동의 한 경우 언어 구현자는 그것을 허용하지 않았을 것입니다. 그러한 만장일치로 명확한 최대 값은 거의 없습니다. (행운대로, 그것은 우리에게 인간 프로그래머를 직업으로 유지시키는 것이기 때문입니다!)

이 오류를 잡는 것이 최선의 선택 인 상황을 찾은 것처럼 매우 많이 보입니다. 응용 프로그램은 작동하지만 다른 모든 대안은 작동하지 않으며 결국에는 중요합니다. 모든 "모범 사례"는 단순히 특정 사례에 대한 자세한 분석 대신 시간을 절약하기 위해 일반적 으로 사용될 수있는 많은 사례에 대한 오랜 경험을 요약 한 것입니다 . 귀하의 경우에는 이미 특정 분석을 수행했으며 다른 결과를 얻었습니다. 축하합니다, 당신은 독립적 인 생각을 할 수 있습니다!

스택 오버플로로 인해 메모리 소모와 같이 응용 프로그램이 일관되지 않은 상황이 발생할 수 있습니다. 일부 객체가 중첩 된 내부 메소드 호출의 도움으로 구성되고 초기화되었다고 상상해보십시오. 할당이 실패한 것처럼 불가능한 상태에있을 수도 있지만 솔루션이 여전히 최상의 솔루션이 될 수는 없습니다.)

여기에 JVM 관련 위험이 있는지 모르겠지만 전반적으로 상당히 합리적입니다.

예를 들어, 순진한 퀵 정렬과 같은 재귀 알고리즘 log(n)은 일반적인 경우 스택 깊이를 갖지만 최악의 경우 n스택을 폭파시킬 수있는 깊이로 저하됩니다 .

최악의 경우는 드물고 부분적으로 정렬 된 세트에서 정렬을 다시 시작하면 다시 발생할 가능성이 없으므로 오류가 발생하거나 종료되지 않도록하는 대신 스택 오버플로 예외가 발생했을 때 작업을 다시 시작하는 것이 좋습니다. 전체 응용 프로그램.