[
https://issues.apache.org/jira/browse/SOLR-7170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767332#comment-16767332
]
Christopher Schultz commented on SOLR-7170:
-------------------------------------------
Okay, this totally works. I added 2 lines of code to IndexSchema.java to attach
metadata to the exception and I can get it on the client. Nice.
The question is how does this help anyone else?
One option might be to create a new type of exception called
UndefinedFieldException which adds this metadata to the exception
automatically, and then unmarshals itself on the other end into the same
exception type. So that helps for this one particular case, but is it
appropriate for all the various ways tat Solr can throw an exception?
The nice feature about doing the above is that it's easy to implement and can
be done piecemeal as the needs arise. Each of the items in the original bug
report can be handled individually in whatever way makes the most sense, each
using this same technique to get the data across the wire and into the client.
Thoughts?
> exceptions thrown by SolrJ do not provide sufficient information to
> gracefully handle errors
> --------------------------------------------------------------------------------------------
>
> Key: SOLR-7170
> URL: https://issues.apache.org/jira/browse/SOLR-7170
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
> Affects Versions: 4.10.3
> Reporter: Greg Solovyev
> Priority: Minor
>
> Currently, exceptions thrown by SolrJ are do not provide sufficient
> information that would enable graceful error handling. Here are some examples:
> When a Solr Collection does not exist, SolrJ throws ErrorCode.BAD_REQUEST
> with message "Could not find collection: " or "Could not find collection in
> zk: ". The only part of the exception that hints to the type of problem is
> the message. However, a hardcoded text message is not a reliable point of
> data to be used in exception handling. It would be much cleaner if SolrJ
> expanded its library of Error Codes and used them to specify what type of
> error has occurred. E.g. :
> ErrorCode.CANNOT_FIND_COLLECTION (for the above example)
> ErrorCode.NO_LIVE_NODES (instead of just SolrServerException("No live
> SolrServers available to handle this request"))
> ErrorCode.BAD_RESPONSE (instead of just SolrServerException("Expected JSON
> object in response from ...)
> etc
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
