[
https://issues.apache.org/jira/browse/SOLR-7120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14503066#comment-14503066
]
Shawn Heisey commented on SOLR-7120:
------------------------------------
It looks like simply throwing the original SyntaxError (which is what the
similar code in DisMaxQParser does), or perhaps wrapping the orginal
SyntaxError in the RuntimeException, would have been far better than this.
Looking at how DisMaxQParser.parseQueryFields gets used in both, it appears to
be very different. DisMax uses it in parse(), but ExtendedDismax uses it
during initialization ... which is very odd to me, unless the parser creation
happens on every query. That sounds to me like a very inefficient way of
working.
I was thinking about simply allowing the SyntaxError to bubble up through the
stack, but I'm not sure what the implications of that might be.
> terrible error reporting code in ExtendedDismaxConfiguration
> ------------------------------------------------------------
>
> Key: SOLR-7120
> URL: https://issues.apache.org/jira/browse/SOLR-7120
> Project: Solr
> Issue Type: Bug
> Reporter: Hoss Man
>
> This abomination needs to be changed...
> {noformat}
> try {
> queryFields = DisMaxQParser.parseQueryFields(req.getSchema(),
> solrParams); // req.getSearcher() here causes se$
> } catch (SyntaxError e) {
> throw new RuntimeException();
> }
> {noformat}
> If you don't have a qf or df param in your request (ex: bin/solr -e cloud
> using "basic_configs") this causes a completely unhelpful RuntimeException to
> be thrown.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
