On 4/26/05, Daniel Naber <[EMAIL PROTECTED]> wrote:
> On Tuesday 26 April 2005 21:09, Erik Hatcher wrote:
>
> > I don't know.... would it? I have no preference, though it seems ok to
> > me to simply return null since this is the toString method. For a
> > Document, the toString is only useful for debugging anyway.
>
> Yes, and during debugging it would be especially confusing to just hide the
> exception. Sure, people will see that there's a problem with a "null"
> document, but then why not show the exception directly?
>
Rather than return null, or throw an undesirable RuntimeException from the
toString() method, it may be more useful for the toString() to indicate the
critical parameters of the promised Hit, rather than the String representation
of one of the underlying members.
How about replacing the toString() method in Hit.java with...
/**
* Prints the parameters to be used to discover the promised result.
*/
public String toString() {
StringBuffer buffer = new StringBuffer();
buffer.append("Hit<");
buffer.append(hits.toString());
buffer.append(" [");
buffer.append(hitNumber);
buffer.append("] ");
if (resolved) {
buffer.append("resolved");
} else {
buffer.append("unresolved");
}
buffer.append(">");
return buffer.toString();
}
which will return something like
"Hit<[EMAIL PROTECTED] [5] unresolved>"
and no RuntimeException or null in sight.
If the user of the API wants to deal with the potential IOException, then
they would write hit.getDocument().toString() and act accordingly.
Hope this helps,
jez.
--
http://javanicus.com/blog2
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
