TrieTokenizerFactory should catch NumberFormatException, return 400 (not 500)
-----------------------------------------------------------------------------
Key: SOLR-2813
URL: https://issues.apache.org/jira/browse/SOLR-2813
Project: Solr
Issue Type: Bug
Components: Schema and Analysis
Affects Versions: 4.0
Environment: 4.0 trunk, snapshot taken 09/08/2011.
Reporter: Jeff Crump
Priority: Minor
TrieTokenizerFactory is allowing bad user input to result in a 500 error rather than a 400.
For a long-valued field, for example, this code in TrieTokenizerFactory.reset() will throw
a NumberFormatException:
> case LONG:
> ts.setLongValue(Long.parseLong(v));
> break;
The NFE gets all the way out to RequestHandlerBase.handleRequest():
> catch (Exception e) {
> SolrException.log(SolrCore.log,e);
> if (e instanceof ParseException) {
> e = new SolrException(SolrException.ErrorCode.BAD_REQUEST, e);
> }
but is not caught here, and ends up coming out of SolrDispatchFilter.sendError as a 500.
Simply catching NFE and turning it into a SolrException does the trick:
==== solr/core/src/java/org/apache/solr/analysis/TrieTokenizerFactory.java#1 - /4.0-trunk-09082011/solr/core/src/java/org/apache/solr/analysis/TrieTokenizerFactory.java
====
110a111,112
> } catch (NumberFormatException e) {
> throw new SolrException(SolrException.ErrorCode.BAD_REQUEST, "Unable to parse
input", e);
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
|