[
https://issues.apache.org/jira/browse/SOLR-2682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13073267#comment-13073267
]
Koji Sekiguchi commented on SOLR-2682:
--------------------------------------
Uh, good point. I'll check.
> remove addException() from SimpleFacet
> --------------------------------------
>
> Key: SOLR-2682
> URL: https://issues.apache.org/jira/browse/SOLR-2682
> Project: Solr
> Issue Type: Improvement
> Components: search
> Affects Versions: 1.1.0, 1.2, 1.3, 1.4.1, 3.1, 3.2, 3.3, 4.0
> Reporter: Koji Sekiguchi
> Assignee: Koji Sekiguchi
> Priority: Minor
> Fix For: 3.4, 4.0
>
> Attachments: SOLR-2682.patch
>
>
> addException() which is super historic, pre-apache code, should be removed
> from SimpleFacet. Hoss described in the mail thread
> http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201107.mbox/%3Calpine.DEB.2.00.1107281651200.12738@bester%3E
> {quote}
> : If I got an exception during faceting (e.g. undefined field), Solr doesn't
> : return HTTP 400 but 200 with the exception stack trace in <arr
> name="exception">
> : ...</arr> tag. Why is it implemented so? I checked Solr 1.1 and saw the
> same behavior.
> super historic, pre-apache, code ... the idea at the time was that some
> parts of the response (like faceting, highlightin, watever...) would be
> "optional" and if there was an error computing that data it wouldn't fail
> the main request.
> that logic should really be ripped out.
> {quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
