On Wednesday 26 November 2003 05:08, Erik Hatcher wrote: > On Wednesday, November 26, 2003, at 06:51 AM, Otis Gospodnetic wrote: > > Hm, I'm not sure if I like this change. > > Yes, this change makes it easier to handle TooManyClauses exception, > > but the cause exception has nothing to do with parsing, and wrapping it > > in ParseException hides that. > > It sort of does have something to do with the parsing though.... in > that something the user typed parsed to an invalid query.
I kind of agree with Eric here; unchecked exceptions/errors should be something truly erroneous (running out of memory, file descriptors, or such), and a term expanding to too big a list seems like something that should be expected. And as to having to use 'try - catch'; there's no need to do that if you don't want to handled exception, just declare it as being thrown by method; which is a good practice to do even for unchecked exceptions IMO (for one because then Javadocs list them). So at very least parse methods should declare runtime errors as being thrown if they can be thrown. On the other hand, requiring new non-compatible checked exception would break existing applications (signature changing), so it'd be nice if there was common root exception. But here I agree with Otis; this is not really related to parsing per se. It looks like the main problem might be that Lucene core does not separate (or rather, enforce separition of) two specific parts well; parsing (which does not depend in index eventually queries against), and execution of query, which depends on index. In latter case, potentially valid query (regarding parsing) may be invalid to execute against specific index. I noticed this same distinction when working a bit on creating generic way of accessing query terms; there is functional distinction between 'abstract' terms (index independent, from query), and 'concrete' ones (wild card matches expanded to terms that are in specific index). It would make sense to me to have 2 base exceptions; one for parsing, another for execution. "Too many expanded terms" should belong to second category; ParseException should only result from malformed queries? Would it therefore be possible to create new exception, QueryExecutionException (or SearchExecutionException) or something? -+ Tatu +- > > > I prefer leaving things like before. Anyone who uses Lucene for > > serious business should have read the Javadoc for various queries, and > > not just the QueryParser, so complaining that this is only documented > > in BooleanQuery javadoc is not a good excuse, IMHO. > > I tend to disagree with this. And perhaps it has to do with my > opinions on exceptions. Runtime exceptions are pretty rude if they > were meant to be caught. QueryParser is for attaching a UI for user > entered queries. > > I would agree with you more if TooManyClauses was a checked exception > so that it would have to be dealt with for developers using QueryParser. > > > Furthemore, anyone who uses QueryParser should know that ParseException > > will be thrown every once in a while, when users enter a query with > > invalid syntax, and such. Entering a Prefix or Wildcard query that > > results in more than 1024 BooleanQueries is not the result of invalid > > query syntax, but indicates a different problem, which those running > > the Lucene-based application may want to know about and handle > > differently. > > > > What do you think? > > I still think the only thing that should come from the parse method is > a ParseException, unless it is truly a runtime exception that could not > be handled any other way. > > I'm fine backing it out if that is the consensus, but I personally as a > user of QueryParser myself am not fond of the mysterious runtime > exceptions thrown from within Lucene's codebase propagating all the way > back out rather than being wrapped. > > Erik > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
