Java中捕获toString方法异常：为何捕获Throwable？

Great question! I totally get why this would stand out—most of us are drilled to avoid catching Throwable unless we have an extremely specific reason. Let's unpack why this approach makes sense for a method designed to be "safe" when converting objects to strings.

First, let's recap the code we're looking at:

private static String safeToString(Object obj) {
    if (obj == null) return null;
    try {
        return obj.toString();
    } catch (Throwable t) {
        return "Error occured";
    }
}

Why Catch Throwable Instead of Just Exception? #

Java's Throwable is the parent class of both Exception (which includes checked and runtime exceptions like NullPointerException) and Error (system-level issues like StackOverflowError or OutOfMemoryError). Here's why covering both matters for this method:

• Defending against unexpected Errors in custom toString() implementations
  While it's rare, a poorly written toString() could trigger an Error. Imagine a class whose toString() recursively references itself without a base case—this would throw a StackOverflowError. Or a toString() that tries to allocate a huge amount of memory, triggering OutOfMemoryError. If this method only caught Exception, these Errors would bubble up and potentially crash the entire thread (or even the application) just because we tried to convert an object to a string.

• Upholding the "safe" contract
  The whole point of safeToString is to guarantee that calling it won't throw any exception—no matter what the input object does. If we only caught Exception, we'd break that promise. For example, if this method is used in a logging pipeline, we don't want a bad toString() to take down the entire logging system, which could leave us blind to what's actually going wrong in the application.

• Practicality over strict "best practice" dogma
  It's true that Errors are generally considered unrecoverable at the application level. But in this context, we're not trying to recover the entire application—we're just trying to make sure this single method call doesn't fail. Returning "Error occured" gives the caller a useful hint that something went wrong with the conversion, instead of letting a catastrophic error derail the entire flow.

A Caveat #

This approach isn't without tradeoffs. Catching Throwable could mask serious system issues (like a persistent OutOfMemoryError) that you'd want to surface immediately. But for a utility method whose sole purpose is to safely generate a string representation—especially in contexts like logging, debugging, or monitoring where failure to generate the string shouldn't break the main logic—it's a reasonable compromise.

内容的提问来源于stack exchange，提问作者Java Dude