lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Rayner <>
Subject Re: svn commit: r164695 - in /lucene/java/trunk: CHANGES.txt src/java/org/apache/lucene/search/ src/java/org/apache/lucene/search/ src/java/org/apache/lucene/search/ src/test/org/apache/lucene/
Date Tue, 26 Apr 2005 21:09:39 GMT
On 4/26/05, Daniel Naber <> 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 with...

   * Prints the parameters to be used to discover the promised result.
  public String toString() {
      StringBuffer buffer = new StringBuffer();
      buffer.append(" [");
      buffer.append("] ");
      if (resolved) {
      } else {
      return buffer.toString();

which will return something like 
  "Hit< [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,


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message