You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Christopher Schultz (JIRA)" <ji...@apache.org> on 2019/02/13 15:26:01 UTC
[jira] [Commented] (SOLR-7170) exceptions thrown by SolrJ do not
provide sufficient information to gracefully handle errors
[ https://issues.apache.org/jira/browse/SOLR-7170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767305#comment-16767305 ]
Christopher Schultz commented on SOLR-7170:
-------------------------------------------
I'd settle for simple things like being able to tell that the query failed because a field name was incorrect.
There are many use-cases where a user's raw query is being sent-over to Solr for fulfillment. An example response might be an exception with the text:
{{{color:#333333}org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server a{color}t [http://localhost:8983/solr/users]: unde{color:#333333}fined field bad_field{color}}}
While that may be readable and understandable by any programmer and many non-programmers, it will not be understood by someone who cannot read English. My product needs to be able to provide error messages in the preferred language of the user, and it appears that the only (current) way to do that is to parse the text of the exception's "message" field. Yuck.
There is currently "metadata" available from the exception object. Perhaps the amount of "metadata" could be increased to provide more information, here? For example, if the error is that a field is bad, a "detail" key could perhaps include a "bad-field" value, indicating the problem. Another "fieldnames" key could indicate the name(s) of the field(s) that were invalid. This would easily be able to be detected in client code and handled in a localized way.
Once that metadata is available, it would even be possible to throw a more-specific exception type such as BadFieldNameException with a getFieldNames() method for ease-of-use.
I'd be happy to hack on the client side of this, but I'm not sure where I'd start on the server-side. I can see this part of the server-side exception stack trace:
{{2019-02-13 15:22:45.955 ERROR (qtp443290224-20) [ x:users] o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: undefined field field}}
{{ at org.apache.solr.schema.IndexSchema.getDynamicFieldType(IndexSchema.java:1292)}}
{{ at org.apache.solr.schema.IndexSchema$SolrQueryAnalyzer.getWrappedAnalyzer(IndexSchema.java:434)}}{{ ....}}
{{}}So that's a starting point, of course, but I'm not sure how the exception gets turned into data on the wire for returning to the client.
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org