Hi, Using an unchecked exception would help but gives a backward compatibility issue (which is for us no problem though but it might be for others). As Stefan already mentioned previously in the thread, there are several situations in which it is desired that the node iterator skips entries (access control, nodes deleted by another thread, ...). It would be nice if the code in the LazyScoreNodeIterator.fetchNext() method could check the cause of the RepositoryException and then, if it is a real unexpected error such as a broken database connection, throw an unchecked exception.
Best wishes, Martijn -- Martijn Hendriks <GX> creative online development B.V. t: 024 - 3888 261 f: 024 - 3888 621 e: [EMAIL PROTECTED] Wijchenseweg 111 6538 SW Nijmegen http://www.gx.nl/ > -----Original Message----- > From: Jukka Zitting [mailto:[EMAIL PROTECTED] > Sent: Monday, August 27, 2007 12:13 PM > To: dev@jackrabbit.apache.org > Subject: Re: Database connections & queries > > Hi, > > On 8/27/07, Thomas Mueller <[EMAIL PROTECTED]> wrote: > > > We could change the behaviour of the iterator to throw a > NoSuchElementException. > > > That's an exception already declared on nextNode(). > > > > What about a new JackrabbitRuntimeException? > NoSuchElementException is > > a RuntimeException as well. NoSuchElementException means "the > > iteration has no more elements", and is thrown if next() was called > > too many times. I prefer fewer exception classes, but in this case > > reusing NoSuchElementException doesn't feel right (to me), > because the > > same exception is thrown for a common user error (not calling or > > ignoring hasNext()), and internal problems like dropped connections. > > +1 Using NoSuchElementException would make it difficult for a client > to determine the real cause of the failure. > > This is actually something we may want to take up in JSR 283, > perhaps even going as far as adding a RepositoryException to > nextNode()... > > BR, > > Jukka Zitting >
