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 01:27:39 GMT

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

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

bq. This only makes sense if callers can catch the exception and handle it differently than
they would other exceptions (I could see this possibly being used in the future though).

That's the whole point of having this issue. Why catch a RuntimeException, or (generic) SolrException,
when I can catch an explicit exception type? I'd rather have more information as a client
than less. Right now, I see what you've done with SolrException and the whole error code process.
The alternative to that is to have explicit SolrException types, e.g., BadRequestException
or ForbiddenException. Better yet, a hybrid of the two would also be great. Something like:

{code}
public class BadRequestException extends SolrException{

  // ...
   public BadRequestException(String msg){
      super(SolrException.ErrorCode.BAD_REQUEST, msg);
    }
 // ...
}
{code}

I'm proposing something like this type of exception for FieldValidation for the #toInternal
method. This way, we design for the future in case someone thinks of new places that FieldType#toIternal
should be called. The reason I'm proposing adding an explicit SolrException.ErrorCode constant
is that I'm not sure that FieldValidation fits into any of the {BAD_REQUEST, FORBIDDEN, NOT_FOUND,
SERVER_ERROR, SERVICE_UNAVAILABLE, UNAUTHORIZED, UNKNOWN} set... 

      was (Author: chrismattmann):
    bq. This only makes sense if callers can catch the exception and handle it differently
than they would other exceptions (I could see this possibly being used in the future though).

That's the whole point of having this issue. Why catch a RuntimeException, or (generic) SolrException,
when I can catch an explicit exception type? I'd rather have more information as a client
than less. Right now, I see what you've done with SolrException and the whole error code process.
The alternative to that is to have explicit SolrException types, e.g., BadRequestException
or ForbiddenException. Better yet, a hybrid of the two would also be great. Something like:

{code}
public class BadRequestException extends SolrException{

  // ...
   public BadRequestException(String msg){
      super(SolrException.ErrorCode.BAD_REQUEST, msg);
    }
 // ...
}
{code}

I'm proposing something like this type of exception for FieldValidation for the #toInternal
method. This way, we design for the future in case someone thinks of new places that FieldType#toIternal
should be called...
  
> 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