On Tuesday, December 2, 2003, at 07:43 AM, Otis Gospodnetic wrote:
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
My vote is with option 3.
Scott
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I'm for the option that is not listed below. :)
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 ParseEr
I vote for option 3.
Since IOExceptions are already caught by current applications,
wrapping the TooManyClauses exception into IOException is
better than having a RuntimeException, which might break old
applications.
Christoph
-
On Monday, December 1, 2003, at 01:02 PM, Doug Cutting wrote:
Wow! What a tempest in a teapot this one has become!
Oops... sorry!
Here are the options as I see them.
3. Change TooManyClauses to extend IOException.
IOException is already thrown by all of the search methods in
question, so that
I haven't been following this thread closely because I don't use the
wildcard queries, which I think are the main source of this exception,
but I agree with Doug's choice below - option 3 at least until 2.0. This
is assuming that option 0 - do nothing, is not an option at this point.
Dmitry.
D
Wow! What a tempest in a teapot this one has become!
Here are the options as I see them.
1. Change TooManyClauses to directly extend Exception.
This is unacceptable. We cannot force all developers to change their
code for a point release.
2. Disable the feature by default.
This would be a s
