lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (Resolved) (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (SOLR-2813) TrieTokenizerFactory should catch NumberFormatException, return 400 (not 500)
Date Thu, 17 Nov 2011 00:23:53 GMT

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

Hoss Man resolved SOLR-2813.
----------------------------

       Resolution: Fixed
    Fix Version/s:     (was: 3.5)

Sorry ... I've given up on trying to backport this to 3x.

After beating my head against a wall trying to merge r1054124, I just manually hacked the
cahnges in, got all existing tests to pass, and then backported r1202499 only to discover
that on the 3x branch TrieTokenizerFactory evidently isn't used in all the same places, so
the NFE was propagating all the way up.

I'm moving on to other things, so resolving this for now.  Can be re-opened as needed if someone
decides to tackle the backport.
                
> 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: 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