Tapestry Training -- From The Source

Let me help you get your team up to speed in Tapestry ... fast. Visit howardlewisship.com for details on training, mentoring and support!

Wednesday, August 13, 2003

Importance of toString()

I'm always dissapointed when I use some else's code (open-source or proprietary -- though its worse for proprietary) and the objects I get back from that code don't implement toString().

One of the main goals of Tapestry is feedback: when things go wrong, provide the developer with as much information as possible to correct the problem. HiveMind follows the same path, crafting useful exception messages, and providing the same line-precise exception reporting as Tapestry. Every object ever made visible to the client code (the code that uses HiveMind) will implement toString().

It's not that hard, folks!. HiveMind and Tapestry mostly use ToStringBuilder from Jakarta commons-lang. I don't really care about efficiency ... toString() generally gets invoked only in a worst-case situation, where the code is already throwing a stack trace or such. What's important is that the developer be provided with as much useful information as possible ... but not overwhelmed with extraneous detail (see my earlier blog about excessive exception logging).

Even the dynamically generated interceptors and proxies in HiveMind get a toString() method; I mean, which would you rather see:

$Proxy_f6f75b1384_25@b6d6ab

or:
<Proxy for hivemind.test.services.BuilderAccess(hivemind.test.services.BuilderAccess)>
The first tells you nothing at all; the second identifies the service and the interface implemented by the proxy. Which is going to kick start your debugging? Next time you write some "reusable" code remember that it can't really be reused unless it can be debugged, and the first step in writing debuggable code is to implement toString().

No comments: