Catching generic Exception in a toString implementation - bad practice?

Yes this is bad practice.

The intention of the toString method is to provide a programmer readable representation of your class. You shouldn't include any method calls in this method, including getters.

In fact, I would consider not autogenerating these methods smelly, but assuming you are not comfortable or able to use an IDE that would produce them for you, I would recommend including a reference to all the fields on the object, and the class name of the object, as is done by the intellij toString method


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.


The main reason not to catch generic Exception at any place is that it will include RuntimeExceptions too, which should not be catched on normal circumstances, because they always represent a bug in the program. It's better to let them be propagated and arise, so that the developer can notice it and eventually fix it.

I don't know if any additional good practice checks shall be applied in the case of toString methods, but I'm sure at least the general rule should be applied.

So, the best practice is always to catch only checked exceptions, and then either recover, either rethrow them, or either rewrap them into another exception (which is your case).