I'm for leaving it as it was before this exception was wrapped in ParseError/Exception. This seemed to work well for a long time, as we didn't hear anyone complain about it until recently one person asked why this exception is not wrapped in ParseError/Exception.
But, the ParseException thing is only one minor area where this could happen. As Doug has said, the TooManyClauses exception would more likely be thrown from IndexSearcher.search.
If this is not an option, then I am in favour of leaving it as it is currently in CVS (wrapped in ParseError/Exception). (What bothers me about this approach is not the wrapping part, but wrapping in something called _Parse_.... I'd be happier if we used something more generic, from which one can optionally getCause() or some such.)
Like I've said, though, I view it as a "parse" exception because it is something the user entered that is not usable. I understand your naming concern here, but having a Lucene runtime exception bubble out of the parse method seems mighty rude to me. If I was implementing a system using QueryParser and I knew of that, I'd just implement two catch statements around QueryParser.parse and catch it and deal with it exactly as I would a ParseException - present a friendly message to the user and say "oops, try again".
I cannot imagine anyone would deal with the exceptions differently from one another. Would you?
Erik
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
