[
https://issues.apache.org/jira/browse/SOLR-10833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16043175#comment-16043175
]
Hoss Man commented on SOLR-10833:
---------------------------------
bq. Note that the DV queries and range queries fail for both, point and trie.
HA! ... Sorry: i didn't even think to double check that, i just noted what was
failing when i tried to swap Point fields on the SOLR-10807 branch and then
beefed up the test to demonstrate.
bq. Here is another patch with some more tests and fixes.
Instead of wrapping so much code in new try/catch/rethrow blocks, perhaps we
should add some replacement/wrapper methods for the various
{{java.lang.Foo.parseFoo(String)}} methods that take care of throwing the
BAD_REQUEST, and refactor all the Trie fields to use those as well ?
something like...
{code}
public interface DoubleValueFieldType extends NumericValueFieldType {
/**
* wraper for {@link Double.parseDouble} that throws a BAD_REQUEST error if
the input is not valid
* @param field used in any exception, may be null
* @param val string to parse, NPE if null
*/
public default double parseDouble(String field, String val) {
if (null == input) throw new NullPointerException("nocommit");
try {
return Double.parseDouble(val);
} catch (NumberFormatException e) {
String msg = "Invalid Number: " + val + (null == field ? "" : " for field
" + field);
throw new SolrException(SolrException.ErrorCode.BAD_REQUEST, msg);
}
}
{code}
WDYT?
> 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
>
>
> 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.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
