lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SOLR-2813) TrieTokenizerFactory should catch NumberFormatException, return 400 (not 500)
Date Wed, 16 Nov 2011 01:32:51 GMT

     [ https://issues.apache.org/jira/browse/SOLR-2813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Hoss Man updated SOLR-2813:
---------------------------

    Affects Version/s: 3.4
        Fix Version/s: 4.0
                       3.5
             Assignee: Hoss Man

Jeff: thanks for reporting this.

I've committed a match similar to what you proposed (except with slightly different scoping
so we can include the value in the error message) to trunk...

Committed revision 1202499.

...and i'm currently testing the backport to 3x
                
> 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: 3.4, 4.0
>         Environment: 4.0 trunk, snapshot taken 09/08/2011.
>            Reporter: Jeff Crump
>            Assignee: Hoss Man
>            Priority: Minor
>             Fix For: 3.5, 4.0
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> 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


Mime
View raw message