Exceptions are difficult to parse

Elastic Stack Elasticsearch
1

I've found that parsing exceptions from the Java client or a REST client is
a PITA. This is especially true for search when you are getting exceptions
from numerous shards. Does anyone have a solution to this?

Shay: Have you considered returning the exception data as JSON instead of
serialized strings?

Mark

2

What are you parsing it for? Are you looking for something specific? The
REST status code (associated with an ElasticSearchException, or returned as
part of the HTTP response) is usually the one you need.

On Fri, Jan 20, 2012 at 10:31 PM, Mark Waddle mark@markwaddle.com wrote:

I've found that parsing exceptions from the Java client or a REST client
is a PITA. This is especially true for search when you are getting
exceptions from numerous shards. Does anyone have a solution to this?

Shay: Have you considered returning the exception data as JSON instead of
serialized strings?

Mark

3

I'm using the Java client and I'm passing a Lucene query string from the
user to ES. In cases where the user provides an invalid query, I am trying
to determine where the user went wrong based on the exception, but it is a
challenge. After thinking about it some more I realize that even if the
nested exception data from each shard was available in an object it would
not be useful because it is usually the Lucene query parser error of "was
expecting one of #@$)@#U$". I'm sure you know the one. For now I think I am
going to simply notify the user that there is an error in their query and
point them to some help.

It might still be useful however to provide the shard exceptions as objects
instead of just a large string for other purposes though.

Mark

4

Yea, for your need, even if it was broken down to an "object", it would
still be problematic because of how the parsing failure is raised and
constructed.

On Tue, Jan 24, 2012 at 5:21 AM, Mark Waddle mark@markwaddle.com wrote:

I'm using the Java client and I'm passing a Lucene query string from the
user to ES. In cases where the user provides an invalid query, I am trying
to determine where the user went wrong based on the exception, but it is a
challenge. After thinking about it some more I realize that even if the
nested exception data from each shard was available in an object it would
not be useful because it is usually the Lucene query parser error of "was
expecting one of #@$)@#U$". I'm sure you know the one. For now I think I am
going to simply notify the user that there is an error in their query and
point them to some help.

It might still be useful however to provide the shard exceptions as
objects instead of just a large string for other purposes though.

Mark