Is it safe to catch stack overflows? Can it leave objects in messy/intermediate states?

Question

I've been reviewing ways to kill threads in Java, and the overwhelming conclusion is that it is never safe to stop code at arbitrary points - doing so may leave resources in messy intermediate states. This is why Thread.stop() was deprecated forever and eventually removed in favor of cooperative thread management.

However, it occurs to me that this is exactly what a stack overflow does - it may be thrown from (as I understand it) any line of java code that tries to reach for more stack space than is available. If you catch a stack overflow exception from an arbitrary thread (in my use case, semi-trusted user code), can that mean runtime objects are left in illegal states? (Un-released locks, open connections, "atomic" operations stopped halfway thru?)

Answer 1

A stack overflow in Java is a StackOverflowError, not a StackOverflowException.

The documentation of Error specifies

An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch.

As you have correctly observed, a StackOverflowError may occur at any point in a program and may leave objects in arbitrarily broken states. You cannot reasonably recover from a StackOverflowError.

Do not try.

Answer 2

Is it safe to catch stack overflows? Can it leave objects in messy/intermediate states?

TL;DR - Sometimes yes, sometimes no.

First of all, catching an Error is not dangerous per se. The (potential) danger is in what you attempt to do after catching it. (And not catching the Error is not always totally safe either.)

Some kinds of Error are not recoverable. For example, if you attempt to recover from a NoClassDefFoundError, there is no way (short of discarding the classloader) to get into a state where you can retry the load of the class ... or any other class that depends on it.

Other kinds of Error are recoverable in some circumstances, but not in general. For example a OutOfMemoryError caused by allocating an array that is too large is recoverable if you can abandon the computation (or whatever) that required the large array. But an OOME that is due to a memory leak is not (fully) recoverable.

Then there is the problem of data structures (or threads) left in inconsistent states. Sometimes these are recoverable; e.g. if the data structures are designed to be atomic, or they can simply be discarded. In others, attempting to recover can lead to other problems. For example, if you get an OOME on one thread that second thread is waiting on, the latter thread may get stuck waiting on a notify or a higher level event that can never occur.

---

What about StackOverflowError?

Well, some of the problems above apply too, but not others. Also, an SOE will (in practice) only occur when you are making a method or constructor call ... though that call may not be explicit.

Furthermore, attempting to recover from an arbitrary Exception or RuntimeException can also lead to problems with corrupt data structures, stuck threads and so on. Indeed, even catching and recovering from NullPointerExceptions (or similar) is potentially risky ... in that you might catch an NPE caused by something that you didn't anticipate, and that your recovery code can't cope with.

---

So what should you do?

Well ... not trying to catch and recover from a StackOverflowError is a sound strategy. But sometimes you just have to¹. So I recommend that before writing code that catches and attempts to recover from a StackOverflowError, you should analyze the problem thoroughly to:

1. make sure you understand the scenarios in which an SOE can occur,
2. make sure that your recovery won't lead to corrupt data structures, stuck threads, resource leaks and so on.

Kinda obvious. No magic bullets here.

---

^{1 - Or you think you have to ... because you haven't yet given sufficient consideration to possible alternatives.}