lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris A. Mattmann (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (SOLR-1589) Make FieldType#toInternal throw explicit Exceptions when Field values don't validate
Date Mon, 23 Nov 2009 02:49:39 GMT

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

Chris A. Mattmann edited comment on SOLR-1589 at 11/23/09 2:48 AM:
-------------------------------------------------------------------

I'm looking to come up with a solution that covers both non-RPC interactions, as well as non-client/server,
framework-related interactions, regardless. I guess the whole idea is whether or not you are
in code:

{code}
//some SOLR class that deals with FieldTypes
// FieldType: myFieldType
try{
  myFieldType.toInternal(//some string)
}
catch(InvalidFieldException e){
//something..
}
{code}

versus being in an RPC interaction:

{code}
curl $URL --data-binary @myFile.xml f -H 'Content-type:text/xml; charset=utf-8'
org.apache.solr.InvalidFieldException: Some brilliant message....
some stacktrace...
{code}

I think we should let the caller know it's a org.apache.solr.InvalidFieldException. That's
my whole point. So, +1 for that. SolrException is probably a good candidate either way, since
SolrException codes, whether sent across the wire, or used internally, should be _mapped_
to HttpResponse codes, and _not_ treated as equivalent, IMHO.



      was (Author: chrismattmann):
    I'm looking to come up with a solution that covers both non-RPC interactions, as well
as non-client/server, framework-related interactions, regardless. I guess the whole idea is
whether or not you are in code:

//some SOLR class that deals with FieldTypes
// FieldType: myFieldType
try{
  myFieldType.toInternal(//some string)
}
catch(InvalidFieldException e){
//something..
}

versus being in an RPC interaction:

curl $URL --data-binary @myFile.xml f -H 'Content-type:text/xml; charset=utf-8'
org.apache.solr.InvalidFieldException: Some brilliant message....
some stacktrace...

I think we should let the caller know it's a org.apache.solr.InvalidFieldException. That's
my whole point. So, +1 for that. SolrException is probably a good candidate either way, since
SolrException codes, whether sent across the wire, or used internally, should be _mapped_
to HttpResponse codes, and _not_ treated as equivalent, IMHO.


  
> 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-22935B6887B4@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.


Mime
View raw message