[ 
https://issues.apache.org/jira/browse/SOLR-10833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16048068#comment-16048068
 ] 

Hoss Man commented on SOLR-10833:
---------------------------------

bq. Here is a new patch.

+1 ... my only nitpicks would be that maybe the {{if (val == null)}} logic 
could be refactored into a {{private static}} helper method?  ... allthough i 
guess in theory even the try/catch/rethrow could be refactored into private 
helper that used a closure? ... not sure how far down the rabbit hole of 
refactoring we can go before less duplication is more confusing.

(just to be clear: totally happy with committing as is)

bq. For some QParsers Points maybe should work (raw, simple...), but I think 
they deserve their own Jiras/discussion if they don't have one already.

yeah, that seems out of scope from the focus here: making the behavior _inside_ 
these FieldTypes classess/methods consistent on bad input

> Numeric FooPointField classes inconsistent with TrieFooFields on malformed 
> input: throw NumberFormatException
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: SOLR-10833
>                 URL: https://issues.apache.org/jira/browse/SOLR-10833
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Hoss Man
>            Assignee: Tomás Fernández Löbbe
>         Attachments: SOLR-10833.patch, SOLR-10833.patch, SOLR-10833.patch, 
> SOLR-10833.patch
>
>
> Trie based Numeic fields deal with bad input by wrapping 
> NumberFormatExceptions in w/BAD_REQUEST SolrExceptions -- PointFields are 
> just allowing the NumberFormatExceptions to be thrown as is, which means they 
> propagate up and are eventually treated as a SERVER_ERROR when responding to 
> clients.
> This is not only inconsistent from an end user perspective -- but also breaks 
> how these errors are handled in SolrCloud when the requests have been 
> forwarded/proxied.
> We should ensure that the FooPointField classes behave consistently with the 
> TrieFooField classes on bad input (both when adding a document, or query 
> creating a field query)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to