From java-dev-return-9938-apmail-lucene-java-dev-archive=lucene.apache.org@lucene.apache.org Tue Apr 26 21:09:51 2005 Return-Path: Delivered-To: apmail-lucene-java-dev-archive@www.apache.org Received: (qmail 49872 invoked from network); 26 Apr 2005 21:09:51 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 26 Apr 2005 21:09:51 -0000 Received: (qmail 72421 invoked by uid 500); 26 Apr 2005 21:10:34 -0000 Delivered-To: apmail-lucene-java-dev-archive@lucene.apache.org Received: (qmail 72067 invoked by uid 500); 26 Apr 2005 21:10:28 -0000 Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-dev@lucene.apache.org Delivered-To: mailing list java-dev@lucene.apache.org Received: (qmail 72050 invoked by uid 99); 26 Apr 2005 21:10:27 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=RCVD_BY_IP X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: domain of jeremy.rayner@gmail.com designates 64.233.170.205 as permitted sender) Received: from rproxy.gmail.com (HELO rproxy.gmail.com) (64.233.170.205) by apache.org (qpsmtpd/0.28) with ESMTP; Tue, 26 Apr 2005 14:10:27 -0700 Received: by rproxy.gmail.com with SMTP id b11so43525rne for ; Tue, 26 Apr 2005 14:09:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=iOrWEmzNuYT30eQ5VN/8b0RNkRTHR7VKpqHCvg/HDRa/N8wpp4bAqelSl5b+z4+K7p+V5WXpCorbN1ycfPWGksjwhSEtEyZ9RGnQlFOMFWuCTf7hFyIpHOf81zINSQTR1y0aX4Q4934jEmCWoE6PaSa94QGMzaOWBkc1mlKrxks= Received: by 10.38.59.75 with SMTP id h75mr258673rna; Tue, 26 Apr 2005 14:09:39 -0700 (PDT) Received: by 10.38.76.19 with HTTP; Tue, 26 Apr 2005 14:09:39 -0700 (PDT) Message-ID: <90a60e760504261409326e60f1@mail.gmail.com> Date: Tue, 26 Apr 2005 22:09:39 +0100 From: Jeremy Rayner Reply-To: Jeremy Rayner To: java-dev@lucene.apache.org Subject: Re: svn commit: r164695 - in /lucene/java/trunk: CHANGES.txt src/java/org/apache/lucene/search/Hit.java src/java/org/apache/lucene/search/HitIterator.java src/java/org/apache/lucene/search/Hits.java src/test/org/apache/lucene/TestHitIterator.java In-Reply-To: <200504262151.03268@danielnaber.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050426002155.94510.qmail@minotaur.apache.org> <200504262038.43762@danielnaber.de> <745a9b4a7a23cc308e0851c69b873131@ehatchersolutions.com> <200504262151.03268@danielnaber.de> X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N On 4/26/05, Daniel Naber wrote: > On Tuesday 26 April 2005 21:09, Erik Hatcher wrote: >=20 > > 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. >=20 > Yes, and during debugging it would be especially confusing to just hide t= he > exception. Sure, people will see that there's a problem with a "null" > document, but then why not show the exception directly? >=20 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 representat= ion 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 =3D 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=20 "Hit" 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. --=20 http://javanicus.com/blog2 --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org For additional commands, e-mail: java-dev-help@lucene.apache.org