[
https://issues.apache.org/jira/browse/SOLR-1589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781283#action_12781283
]
Yonik Seeley commented on SOLR-1589:
------------------------------------
bq. but I don't understand it from a I'm coding entirely on the server side and
I'd like to throw an Exception that's catchable on the server-side perspective
This is getting a bit abstract...
For an invalid field value, I assume the error going back to the remote client
needs to boil down to a 400.
If internal code needs to cache and deal with an invalid field value in a
different manner than they would other 400 errors, then subclassing
SolrException and thus allowing server-side code to explicitly catch it seems
like a fine idea. No new error codes are needed for this - the class serves to
define the type of exception.
> Make FieldType#toInternal throw explicit Exceptions when Field values don't
> validate
> ------------------------------------------------------------------------------------
>
> Key: SOLR-1589
> URL: https://issues.apache.org/jira/browse/SOLR-1589
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 1.4
> Environment: My MacBook pro laptop.
> Reporter: Chris A. Mattmann
> Priority: Minor
> Fix For: 1.5
>
>
> As discussed on the mailing list:
> http://mail-archives.apache.org/mod_mbox/lucene-solr-dev/200911.mbox/%3c85641490-9e70-41b3-a32e-22935b688...@apache.org%3e
> I think we can do a better job of having explicit Exceptions when there is a
> problem creating the internal representation of a Field, as defined by
> FieldType#toInternal. Instead of throwing obscure RuntimeExceptions, let's
> create a FieldValidationException explicit type, and make
> o.a.solr.schema.FieldType#toInternal throw this Exception as part of its
> signature.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
