[
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-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.
