[
https://issues.apache.org/jira/browse/SOLR-7170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767305#comment-16767305
]
Christopher Schultz edited comment on SOLR-7170 at 2/13/19 3:25 PM:
--------------------------------------------------------------------
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.
was (Author: [email protected]):
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: [email protected]
For additional commands, e-mail: [email protected]
