Catching generic Exception in a toString implementation - bad practice?

generickycdeveloper :

I have a domain model class which has a toString implementation that looks like this:

public String toString() {
     try {
        return getX() + "\n"
             getY() + "\n"
             getZ(); //etc.
     } catch(Exception e) {
        throw new RuntimeException(e);
     }
}

The methods getX(), getY() and getZ() are not simple getters, they can perform lookups in the background, generally a lookup to a static map of predefined key-value pairs. Some of them had throws SomeCheckedException in their signatures.

My impression is that this is bad practice and a "code smell". The fact that toString() even needs this check is to me a symptom of bad design. But I'm asked by a colleague, what exactly is wrong with catching the generic Exception in a toString(), since the caught Exception is propagated further.

I believe it violates at least the KISS principle, since a simple method like toString() here is indicated as requiring special exception handling.

So is it code smell to have a catch-all block in a toString()?

Answers I found were either for the general scenario of catching generic Exception and I agree with most of them, that if you're doing a generic error handling mechanism or a batch then it's expected to work on generic exceptions. This argument was unconvincing in our discussion, so I'm curious of other opinions.

SDJ :

For the toString() method, catching Exception is not necessarily a bad practice. However, re-throwing it is the problematic part.

The contract for toString() is:

... In general, the toString method returns a string that "textually represents" this object. The result should be a concise but informative representation that is easy for a person to read...

In Effective Java 3rd Edition (Item 12), Bloch further insists:

When practical, the toString method should return all of the interesting information contained in the object.

So, if this requires calling methods that may throw checked exceptions, then so be it, and it makes a lot of sense to catch these exceptions.

However: raised checked exceptions provide information about the state of the object. Consistently with the goal of toString, it may be a good idea to include the exceptional condition in the message returned by toString.

As for why it's a bad idea to throw exceptions from toString, this post provides a great answer.

Recommendation: Catch the checked exceptions using their specific exception type, and integrate this fact in the toString() message, instead of propagating it.