When is it desired to not implement toString() in Java?

Question

A lead developer on my project has taken to referring to the project\'s toString() implementations as \"pure cruft\" and is looking to remove them from the code base.

<

Answer 1

In general, toString() is good stuff. In particular, it is quite useful for debugging.

Implementing toString() is not without costs and risks. Like all code, toString() implementations must be maintained with the rest of the code. This means keeping toString() in sync with class fields. For example, when a field is added or removed, toString() should be updated appropriately (you should be doing this already for methods like hashCode() and equals()).

Implementing toString() incurs risks as well. For example, suppose that two classes in your system have references to instances of the other (a bi-directional link), then an invocation of toString() could lead to a stack overflow due to unbounded recursion as the toString() implementation in each class invokes the toString() implementation of the other class.

If your system has a significant number of out-of-sync toString() methods, or methods that cause bugs like stack overflows, then your colleague might have a reasonable point. Even in such a case, I would simply comment-out the buggy toString() methods and leave them in the code. Each toString() method could be uncommented and updated individually as needed in the future.

Answer 2

I'd keep the toString() implementations. They are invaluable when it comes to debugging, and they can make for good alt text for graphical components.

Answer 3

I think the answer depends on how complicated your toString() methods are, how much work they require to maintain, and how often they get used. Assuming you use toString() often for logging and debugging it doesn't make much sense to remove these methods. But if they are rarely used and require a lot of work to maintain each time something changes in your code, then there is perhaps a valid argument for getting rid of all or some of the toString() methods.

You mentioned something about clients needing to display these objects. From this I'm guessing your code is or contains some kind of library or API that other developers will use. In this case I highly recommend you maintain useful toString() implementations. Even if you don't do a lot of logging and debugging, your clients might and they will definitely appreciate having useful toString() methods that they don't have to write and maintain themselves.

Answer 4

implement always :) As mentioned above, it is invaluable for debugging.

Answer 5

I would say you should implement toString if that is an expected use case or requirement, to display the object as a string representation (either in logs, on the console, or some kind of display tree).

Otherwise, I agree with the developer - every time you change something, the toString can break. You may have to be careful about nulls, etc.

Many times, though, it is in fact used in debugging or in logging, so it isn't obvious that they should be left out at all.

I agree with jsight that if they are already written, and written decently, leave them in at least until they get in the way (such as you actually add a field to a class).

Answer 6

To be fair, said developer here, but not lead developer in any sense.

The original issue is not necessarily about toString(), but about a second method paramString: "With all of its string concatenation and null value checking, paramString is a bug magnet."

See http://code.google.com/p/piccolo2d/issues/detail?id=99