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: [email protected]
For additional commands, e-mail: [email protected]
