# Error handling for HTTP search API **URL:** \ **Category:** Elasticsearch\ **Created:** [May 7, 2015, 4:56am UTC](https://discuss.elastic.co/t/error-handling-for-http-search-api/23583 "2015-05-07T04:56:59Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![Snixtor](https://avatars.discourse-cdn.com/v4/letter/s/f08c70/32.png) [@Snixtor](https://discuss.elastic.co/u/Snixtor)\ **Post date:** [May 7, 2015, 4:56am UTC](https://discuss.elastic.co/t/error-handling-for-http-search-api/23583/1 "2015-05-07T04:56:59Z")
I have an application allowing users to specify the "query" value of a "query\_string" query. If the user inputs invalid search syntax, e.g. their search is only "AND" (an operator without any values), Elasticsearch returns an _exceedingly_ verbose error message with very user-unfriendly text like "failed to execute phase" and "shard failure", when what I really want is a simple user-friendly error like "Bad search syntax". In this particular example, text within the "QueryParsingException" sections is close to what I'm looking for. QueryParsingException[[\] Failed to parse query [AND]] But it's buried in a sea of text. I could parse out any text within the QueryParsingException, but frankly that feels like reverse-engineering. Will _all_ queries with bad syntax have user-friendly error text like this particular example? Is the most user-friendly message always likely to appear within QueryParsingException? Are there other error scenarios I might want to handle that don't even have a QueryParsingException? I've been digging through Elasticsearch documentation for some explanation of the kinds of errors I might expect and what format those error messages will be in, but I'm coming up blank. For what it's worth, I'm integrating using the .NET client _NEST_. ## -- Please update your bookmarks! We moved to [https://discuss.elastic.co/](https://discuss.elastic.co/) You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/94d494a5-9d97-4ace-ab6a-7ba9d1f05734%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/94d494a5-9d97-4ace-ab6a-7ba9d1f05734%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\ **Post date:** [May 7, 2015, 5:01am UTC](https://discuss.elastic.co/t/error-handling-for-http-search-api/23583/2 "2015-05-07T05:01:33Z")
Try simple\_query\_string. BTW we moved to [https://discuss.elastic.co/](https://discuss.elastic.co/) David > Le 7 mai 2015 à 06:56, Snixtor [snixtor@gmail.com](mailto:snixtor@gmail.com) a écrit : > > I have an application allowing users to specify the "query" value of a "query\_string" query. If the user inputs invalid search syntax, e.g. their search is only "AND" (an operator without any values), Elasticsearch returns an exceedingly verbose error message with very user-unfriendly text like "failed to execute phase" and "shard failure", when what I really want is a simple user-friendly error like "Bad search syntax". In this particular example, text within the "QueryParsingException" sections is close to what I'm looking for. > > QueryParsingException[[\] Failed to parse query [AND]] > > But it's buried in a sea of text. I could parse out any text within the QueryParsingException, but frankly that feels like reverse-engineering. Will all queries with bad syntax have user-friendly error text like this particular example? Is the most user-friendly message always likely to appear within QueryParsingException? Are there other error scenarios I might want to handle that don't even have a QueryParsingException? > > ## I've been digging through Elasticsearch documentation for some explanation of the kinds of errors I might expect and what format those error messages will be in, but I'm coming up blank. For what it's worth, I'm integrating using the .NET client NEST. > > ## Please update your bookmarks! We moved to [https://discuss.elastic.co/](https://discuss.elastic.co/) > > You received this message because you are subscribed to the Google Groups "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/94d494a5-9d97-4ace-ab6a-7ba9d1f05734%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/94d494a5-9d97-4ace-ab6a-7ba9d1f05734%40googlegroups.com). > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ## -- Please update your bookmarks! We moved to [https://discuss.elastic.co/](https://discuss.elastic.co/) You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/8326F3E5-FE75-41A8-B6DA-6DF79B5BC7AB%40pilato.fr](https://groups.google.com/d/msgid/elasticsearch/8326F3E5-FE75-41A8-B6DA-6DF79B5BC7AB%40pilato.fr). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![Snixtor](https://avatars.discourse-cdn.com/v4/letter/s/f08c70/32.png) [@Snixtor](https://discuss.elastic.co/u/Snixtor)\ **Post date:** [May 7, 2015, 5:14am UTC](https://discuss.elastic.co/t/error-handling-for-http-search-api/23583/3 "2015-05-07T05:14:37Z")
Regarding the discussion forum, I noticed literally 1 minute after posting this message. Should I duplicate this question in the forum? Can it be moved from the discussion group into the forum? The "we have moved" FAQ didn't address this matter of "transition". Regarding simple\_query\_string, I'm not as fond of the syntax. My application is transitioning from another text search system to Elasticsearch, and the syntax of query\_string is a closer match to what users are familiar with. For example, query\_string uses "AND", while simple\_query\_string uses "+". For the user base, that's possibly a _bigger_ issue than big error messages. On Thursday, 7 May 2015 15:01:55 UTC+10, David Pilato wrote: > Try simple\_query\_string. > > BTW we moved to [https://discuss.elastic.co/](https://discuss.elastic.co/) > > David > > Le 7 mai 2015 à 06:56, Snixtor \<[sni...@gmail.com](mailto:sni...@gmail.com) \\> a écrit : > > I have an application allowing users to specify the "query" value of a > "query\_string" query. If the user inputs invalid search syntax, e.g. their > search is only "AND" (an operator without any values), Elasticsearch > returns an _exceedingly_ verbose error message with very user-unfriendly > text like "failed to execute phase" and "shard failure", when what I really > want is a simple user-friendly error like "Bad search syntax". In this > particular example, text within the "QueryParsingException" sections is > close to what I'm looking for. > > QueryParsingException[[\] Failed to parse query [AND]] > > But it's buried in a sea of text. I could parse out any text within the > QueryParsingException, but frankly that feels like reverse-engineering. > Will _all_ queries with bad syntax have user-friendly error text like > this particular example? Is the most user-friendly message always likely to > appear within QueryParsingException? Are there other error scenarios I > might want to handle that don't even have a QueryParsingException? > > I've been digging through Elasticsearch documentation for some explanation > of the kinds of errors I might expect and what format those error messages > will be in, but I'm coming up blank. For what it's worth, I'm integrating > using the .NET client _NEST_. > > ## -- Please update your bookmarks! We moved to [https://discuss.elastic.co/](https://discuss.elastic.co/) > > You received this message because you are subscribed to the Google Groups > "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com) \. > To view this discussion on the web visit > [https://groups.google.com/d/msgid/elasticsearch/94d494a5-9d97-4ace-ab6a-7ba9d1f05734%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/94d494a5-9d97-4ace-ab6a-7ba9d1f05734%40googlegroups.com) > [https://groups.google.com/d/msgid/elasticsearch/94d494a5-9d97-4ace-ab6a-7ba9d1f05734%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/94d494a5-9d97-4ace-ab6a-7ba9d1f05734%40googlegroups.com?utm_medium=email&utm_source=footer) > . > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ## -- Please update your bookmarks! We moved to [https://discuss.elastic.co/](https://discuss.elastic.co/) You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/c4cfd193-ae36-44fe-bb94-aad0dd374c5d%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/c4cfd193-ae36-44fe-bb94-aad0dd374c5d%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\ **Post date:** [May 7, 2015, 5:35am UTC](https://discuss.elastic.co/t/error-handling-for-http-search-api/23583/4 "2015-05-07T05:35:23Z")
No that's fine to keep this thread here. Well with query\_string you can also use + I did not check but I think that AND might work as well with simple query string. It's not? David > Le 7 mai 2015 à 07:14, Snixtor [snixtor@gmail.com](mailto:snixtor@gmail.com) a écrit : > > Regarding the discussion forum, I noticed literally 1 minute after posting this message. Should I duplicate this question in the forum? Can it be moved from the discussion group into the forum? The "we have moved" FAQ didn't address this matter of "transition". > > Regarding simple\_query\_string, I'm not as fond of the syntax. My application is transitioning from another text search system to Elasticsearch, and the syntax of query\_string is a closer match to what users are familiar with. For example, query\_string uses "AND", while simple\_query\_string uses "+". For the user base, that's possibly a bigger issue than big error messages. > > > On Thursday, 7 May 2015 15:01:55 UTC+10, David Pilato wrote: > > Try simple\_query\_string. > > > > BTW we moved to [https://discuss.elastic.co/](https://discuss.elastic.co/) > > > > David > > > > > Le 7 mai 2015 à 06:56, Snixtor [sni...@gmail.com](mailto:sni...@gmail.com) a écrit : > > > > > > I have an application allowing users to specify the "query" value of a "query\_string" query. If the user inputs invalid search syntax, e.g. their search is only "AND" (an operator without any values), Elasticsearch returns an exceedingly verbose error message with very user-unfriendly text like "failed to execute phase" and "shard failure", when what I really want is a simple user-friendly error like "Bad search syntax". In this particular example, text within the "QueryParsingException" sections is close to what I'm looking for. > > > > > > QueryParsingException[[\] Failed to parse query [AND]] > > > > > > But it's buried in a sea of text. I could parse out any text within the QueryParsingException, but frankly that feels like reverse-engineering. Will all queries with bad syntax have user-friendly error text like this particular example? Is the most user-friendly message always likely to appear within QueryParsingException? Are there other error scenarios I might want to handle that don't even have a QueryParsingException? > > > > > > ## I've been digging through Elasticsearch documentation for some explanation of the kinds of errors I might expect and what format those error messages will be in, but I'm coming up blank. For what it's worth, I'm integrating using the .NET client NEST. > > > > > > ## Please update your bookmarks! We moved to [https://discuss.elastic.co/](https://discuss.elastic.co/) > > > > > > You received this message because you are subscribed to the Google Groups "elasticsearch" group. > > > To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/94d494a5-9d97-4ace-ab6a-7ba9d1f05734%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/94d494a5-9d97-4ace-ab6a-7ba9d1f05734%40googlegroups.com). > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > ## -- Please update your bookmarks! We moved to [https://discuss.elastic.co/](https://discuss.elastic.co/) > > You received this message because you are subscribed to the Google Groups "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/c4cfd193-ae36-44fe-bb94-aad0dd374c5d%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/c4cfd193-ae36-44fe-bb94-aad0dd374c5d%40googlegroups.com). > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ## -- Please update your bookmarks! We moved to [https://discuss.elastic.co/](https://discuss.elastic.co/) You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/E18DB6FC-7FA1-4A84-AC73-D80113AD19FB%40pilato.fr](https://groups.google.com/d/msgid/elasticsearch/E18DB6FC-7FA1-4A84-AC73-D80113AD19FB%40pilato.fr). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![Snixtor](https://avatars.discourse-cdn.com/v4/letter/s/f08c70/32.png) [@Snixtor](https://discuss.elastic.co/u/Snixtor)\ **Post date:** [May 7, 2015, 5:41am UTC](https://discuss.elastic.co/t/error-handling-for-http-search-api/23583/5 "2015-05-07T05:41:28Z")
_"I think that AND might work as well with simple query string"_ Tried just now. Doesn't work, it gets treated as a search term instead of an operator, so is functionally equivalent to "and" in query\_string. I _could_ try translating operators, but a truly robust implementation of that is more work than I would have liked. On 7 May 2015 at 15:35, David Pilato [david@pilato.fr](mailto:david@pilato.fr) wrote: > No that's fine to keep this thread here. > Well with query\_string you can also use + > > I did not check but I think that AND might work as well with simple query > string. It's not? > > David > > Le 7 mai 2015 à 07:14, Snixtor [snixtor@gmail.com](mailto:snixtor@gmail.com) a écrit : > > Regarding the discussion forum, I noticed literally 1 minute after posting > this message. Should I duplicate this question in the forum? Can it be > moved from the discussion group into the forum? The "we have moved" FAQ > didn't address this matter of "transition". > > Regarding simple\_query\_string, I'm not as fond of the syntax. My > application is transitioning from another text search system to > Elasticsearch, and the syntax of query\_string is a closer match to what > users are familiar with. For example, query\_string uses "AND", while > simple\_query\_string uses "+". For the user base, that's possibly a > _bigger_ issue than big error messages. > > On Thursday, 7 May 2015 15:01:55 UTC+10, David Pilato wrote: > > > Try simple\_query\_string. > > > > BTW we moved to [https://discuss.elastic.co/](https://discuss.elastic.co/) > > > > David > > > > Le 7 mai 2015 à 06:56, Snixtor [sni...@gmail.com](mailto:sni...@gmail.com) a écrit : > > > > I have an application allowing users to specify the "query" value of a > > "query\_string" query. If the user inputs invalid search syntax, e.g. their > > search is only "AND" (an operator without any values), Elasticsearch > > returns an _exceedingly_ verbose error message with very user-unfriendly > > text like "failed to execute phase" and "shard failure", when what I really > > want is a simple user-friendly error like "Bad search syntax". In this > > particular example, text within the "QueryParsingException" sections is > > close to what I'm looking for. > > > > QueryParsingException[[\] Failed to parse query [AND]] > > > > But it's buried in a sea of text. I could parse out any text within the > > QueryParsingException, but frankly that feels like reverse-engineering. > > Will _all_ queries with bad syntax have user-friendly error text like > > this particular example? Is the most user-friendly message always likely to > > appear within QueryParsingException? Are there other error scenarios I > > might want to handle that don't even have a QueryParsingException? > > > > I've been digging through Elasticsearch documentation for some > > explanation of the kinds of errors I might expect and what format those > > error messages will be in, but I'm coming up blank. For what it's worth, > > I'm integrating using the .NET client _NEST_. > > > > ## -- Please update your bookmarks! We moved to [https://discuss.elastic.co/](https://discuss.elastic.co/) > > > > You received this message because you are subscribed to the Google Groups > > "elasticsearch" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > To view this discussion on the web visit > > [https://groups.google.com/d/msgid/elasticsearch/94d494a5-9d97-4ace-ab6a-7ba9d1f05734%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/94d494a5-9d97-4ace-ab6a-7ba9d1f05734%40googlegroups.com) > > [https://groups.google.com/d/msgid/elasticsearch/94d494a5-9d97-4ace-ab6a-7ba9d1f05734%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/94d494a5-9d97-4ace-ab6a-7ba9d1f05734%40googlegroups.com?utm_medium=email&utm_source=footer) > > . > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > -- > > Please update your bookmarks! We moved to [https://discuss.elastic.co/](https://discuss.elastic.co/) > > * * * > > You received this message because you are subscribed to the Google Groups > "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > To view this discussion on the web visit > [https://groups.google.com/d/msgid/elasticsearch/c4cfd193-ae36-44fe-bb94-aad0dd374c5d%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/c4cfd193-ae36-44fe-bb94-aad0dd374c5d%40googlegroups.com) > [https://groups.google.com/d/msgid/elasticsearch/c4cfd193-ae36-44fe-bb94-aad0dd374c5d%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/c4cfd193-ae36-44fe-bb94-aad0dd374c5d%40googlegroups.com?utm_medium=email&utm_source=footer) > . > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > ## -- Please update your bookmarks! We moved to [https://discuss.elastic.co/](https://discuss.elastic.co/) > > You received this message because you are subscribed to a topic in the > Google Groups "elasticsearch" group. > To unsubscribe from this topic, visit > [https://groups.google.com/d/topic/elasticsearch/CSmm9zdw1dM/unsubscribe](https://groups.google.com/d/topic/elasticsearch/CSmm9zdw1dM/unsubscribe). > To unsubscribe from this group and all its topics, send an email to > [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > To view this discussion on the web visit > [https://groups.google.com/d/msgid/elasticsearch/E18DB6FC-7FA1-4A84-AC73-D80113AD19FB%40pilato.fr](https://groups.google.com/d/msgid/elasticsearch/E18DB6FC-7FA1-4A84-AC73-D80113AD19FB%40pilato.fr) > [https://groups.google.com/d/msgid/elasticsearch/E18DB6FC-7FA1-4A84-AC73-D80113AD19FB%40pilato.fr?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/E18DB6FC-7FA1-4A84-AC73-D80113AD19FB%40pilato.fr?utm_medium=email&utm_source=footer) > . > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ## -- Please update your bookmarks! We moved to [https://discuss.elastic.co/](https://discuss.elastic.co/) You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CANsC95qnEtcfTORTs%3DFq-qSuHFn3-eeEiv2UC36HLq12eHsv1Q%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CANsC95qnEtcfTORTs%3DFq-qSuHFn3-eeEiv2UC36HLq12eHsv1Q%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\ **Post date:** [May 7, 2015, 3:03pm UTC](https://discuss.elastic.co/t/error-handling-for-http-search-api/23583/6 "2015-05-07T15:03:08Z")
Indeed. The only workaround I can see in addition to the one you found with + is to set `default_operator` to `AND` DELETE simple PUT simple/test/1 { "foo": "bar baz" } PUT simple/test/2 { "foo": "bar boz" } GET simple/\_search { "query": { "simple\_query\_string": { "query": "bar baz", "fields": ["foo"], "default\_operator": "AND" } } } But that’s not exactly what you are looking for. -- David Pilato - Developer | Evangelist > **[Elastic — The Search AI Company](https://www.elastic.co/)** > > Power insights and outcomes with The Elastic Search AI Platform. See into your data and find answers that matter with enterprise solutions designed to help you accelerate time to insight. Try Elastic ... @dadoonet [https://twitter.com/dadoonet](https://twitter.com/dadoonet) | @elasticsearchfr [https://twitter.com/elasticsearchfr](https://twitter.com/elasticsearchfr) | @scrutmydocs [https://twitter.com/scrutmydocs](https://twitter.com/scrutmydocs) > Le 7 mai 2015 à 07:41, Jason [snixtor@gmail.com](mailto:snixtor@gmail.com) a écrit : > > "I think that AND might work as well with simple query string" > > Tried just now. Doesn't work, it gets treated as a search term instead of an operator, so is functionally equivalent to "and" in query\_string. I could try translating operators, but a truly robust implementation of that is more work than I would have liked. > > On 7 May 2015 at 15:35, David Pilato \<[david@pilato.fr](mailto:david@pilato.fr) [mailto:david@pilato.fr](mailto:david@pilato.fr)\> wrote: > No that's fine to keep this thread here. > Well with query\_string you can also use + > > I did not check but I think that AND might work as well with simple query string. It's not? > > David > > Le 7 mai 2015 à 07:14, Snixtor \<[snixtor@gmail.com](mailto:snixtor@gmail.com) [mailto:snixtor@gmail.com](mailto:snixtor@gmail.com)\> a écrit : > > > Regarding the discussion forum, I noticed literally 1 minute after posting this message. Should I duplicate this question in the forum? Can it be moved from the discussion group into the forum? The "we have moved" FAQ didn't address this matter of "transition". > > > > Regarding simple\_query\_string, I'm not as fond of the syntax. My application is transitioning from another text search system to Elasticsearch, and the syntax of query\_string is a closer match to what users are familiar with. For example, query\_string uses "AND", while simple\_query\_string uses "+". For the user base, that's possibly a bigger issue than big error messages. > > > > On Thursday, 7 May 2015 15:01:55 UTC+10, David Pilato wrote: > > Try simple\_query\_string. > > > > BTW we moved to [https://discuss.elastic.co/](https://discuss.elastic.co/) [https://discuss.elastic.co/](https://discuss.elastic.co/) > > > > David > > > > Le 7 mai 2015 à 06:56, Snixtor \<[sni...@gmail.com](mailto:sni...@gmail.com) \<\>\> a écrit : > > > > > I have an application allowing users to specify the "query" value of a "query\_string" query. If the user inputs invalid search syntax, e.g. their search is only "AND" (an operator without any values), Elasticsearch returns an exceedingly verbose error message with very user-unfriendly text like "failed to execute phase" and "shard failure", when what I really want is a simple user-friendly error like "Bad search syntax". In this particular example, text within the "QueryParsingException" sections is close to what I'm looking for. > > > > > > QueryParsingException[[\] Failed to parse query [AND]] > > > > > > But it's buried in a sea of text. I could parse out any text within the QueryParsingException, but frankly that feels like reverse-engineering. Will all queries with bad syntax have user-friendly error text like this particular example? Is the most user-friendly message always likely to appear within QueryParsingException? Are there other error scenarios I might want to handle that don't even have a QueryParsingException? > > > > > > I've been digging through Elasticsearch documentation for some explanation of the kinds of errors I might expect and what format those error messages will be in, but I'm coming up blank. For what it's worth, I'm integrating using the .NET client NEST. > > > > > > ## -- Please update your bookmarks! We moved to [https://discuss.elastic.co/](https://discuss.elastic.co/) [https://discuss.elastic.co/](https://discuss.elastic.co/) > > > > > > You received this message because you are subscribed to the Google Groups "elasticsearch" group. > > > To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com) \<\>. > > > To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/94d494a5-9d97-4ace-ab6a-7ba9d1f05734%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/94d494a5-9d97-4ace-ab6a-7ba9d1f05734%40googlegroups.com) [https://groups.google.com/d/msgid/elasticsearch/94d494a5-9d97-4ace-ab6a-7ba9d1f05734%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/94d494a5-9d97-4ace-ab6a-7ba9d1f05734%40googlegroups.com?utm_medium=email&utm_source=footer). > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout) [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > ## -- Please update your bookmarks! We moved to [https://discuss.elastic.co/](https://discuss.elastic.co/) [https://discuss.elastic.co/](https://discuss.elastic.co/) > > > > You received this message because you are subscribed to the Google Groups "elasticsearch" group. > > To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com) [mailto:elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > > To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/c4cfd193-ae36-44fe-bb94-aad0dd374c5d%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/c4cfd193-ae36-44fe-bb94-aad0dd374c5d%40googlegroups.com) [https://groups.google.com/d/msgid/elasticsearch/c4cfd193-ae36-44fe-bb94-aad0dd374c5d%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/c4cfd193-ae36-44fe-bb94-aad0dd374c5d%40googlegroups.com?utm_medium=email&utm_source=footer). > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout) [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > ## -- Please update your bookmarks! We moved to [https://discuss.elastic.co/](https://discuss.elastic.co/) [https://discuss.elastic.co/](https://discuss.elastic.co/) > > You received this message because you are subscribed to a topic in the Google Groups "elasticsearch" group. > To unsubscribe from this topic, visit [https://groups.google.com/d/topic/elasticsearch/CSmm9zdw1dM/unsubscribe](https://groups.google.com/d/topic/elasticsearch/CSmm9zdw1dM/unsubscribe) [https://groups.google.com/d/topic/elasticsearch/CSmm9zdw1dM/unsubscribe](https://groups.google.com/d/topic/elasticsearch/CSmm9zdw1dM/unsubscribe). > To unsubscribe from this group and all its topics, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com) [mailto:elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/E18DB6FC-7FA1-4A84-AC73-D80113AD19FB%40pilato.fr](https://groups.google.com/d/msgid/elasticsearch/E18DB6FC-7FA1-4A84-AC73-D80113AD19FB%40pilato.fr) [https://groups.google.com/d/msgid/elasticsearch/E18DB6FC-7FA1-4A84-AC73-D80113AD19FB%40pilato.fr?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/E18DB6FC-7FA1-4A84-AC73-D80113AD19FB%40pilato.fr?utm_medium=email&utm_source=footer). > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout) [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > ## -- Please update your bookmarks! We moved to [https://discuss.elastic.co/](https://discuss.elastic.co/) [https://discuss.elastic.co/](https://discuss.elastic.co/) > > You received this message because you are subscribed to the Google Groups "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com) [mailto:elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CANsC95qnEtcfTORTs%3DFq-qSuHFn3-eeEiv2UC36HLq12eHsv1Q%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CANsC95qnEtcfTORTs%3DFq-qSuHFn3-eeEiv2UC36HLq12eHsv1Q%40mail.gmail.com) [https://groups.google.com/d/msgid/elasticsearch/CANsC95qnEtcfTORTs%3DFq-qSuHFn3-eeEiv2UC36HLq12eHsv1Q%40mail.gmail.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/CANsC95qnEtcfTORTs%3DFq-qSuHFn3-eeEiv2UC36HLq12eHsv1Q%40mail.gmail.com?utm_medium=email&utm_source=footer). > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout) [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ## -- Please update your bookmarks! We moved to [https://discuss.elastic.co/](https://discuss.elastic.co/) You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/1C955DCD-6E33-443D-8292-2FD79ADCC567%40pilato.fr](https://groups.google.com/d/msgid/elasticsearch/1C955DCD-6E33-443D-8292-2FD79ADCC567%40pilato.fr). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![Snixtor](https://avatars.discourse-cdn.com/v4/letter/s/f08c70/32.png) [@Snixtor](https://discuss.elastic.co/u/Snixtor)\ **Post date:** [May 7, 2015, 9:14pm UTC](https://discuss.elastic.co/t/error-handling-for-http-search-api/23583/7 "2015-05-07T21:14:23Z")
Indeed. Even if I did tinker with these alternative query styles to avoid syntax errors, there's other error scenarios to consider. What kind of message and error structure could I expect for, say, a critical shard failure? I'd still really like to know: 1. What kind of error reports I can expect, and; 2. What structure those reports will have. I look at, say, C# .NET, where every library method has a clear definition of what exception objects to expect, and in what scenarios. The strongly-typed exception objects make it easy to gracefully handle different errors - [File.Open Method (System.IO) | Microsoft Learn](https://msdn.microsoft.com/en-us/library/b9skfh7s(v=vs.110).aspx) - If on File.Open I get a FileNotFoundException, I can probably blame the user for choosing an invalid file name. But if I get an IOException, I can probably say "oh no, I think there might be a problem with your disk". Or the Twitter REST API where response codes are all clearly defined within the context of the API - [https://dev.twitter.com/overview/api/response-codes](https://dev.twitter.com/overview/api/response-codes) The Twitter advertising API even has the good grace to provide an errors/message node that \*"will indicate a (usually) human-readable description of the error in English" \*- [https://dev.twitter.com/ads/campaigns/response-codes](https://dev.twitter.com/ads/campaigns/response-codes) But I can't find any equivalent documentation for Elasticsearch. The closest I've come so far is this - > **[RESTful API with JSON over HTTP - Talking to Elasticsearch | Elasticsearch: The...](https://www.elastic.co/guide/en/elasticsearch/guide/current/_talking_to_elasticsearch.html#_restful_api_with_json_over_http)** - "Elasticsearch returns an HTTP status code like 200 OK". From which I might _assume_ a full range of HTTP status codes is in use. But... y'know, assumptions. And even with HTTP status codes, unless there's an accompanying (concise) message, it's not easy to determine what's going on. A 400 - Bad Request could mean bad query syntax, or it could mean the query is specifying an index that doesn't exist. As an integrating application, it would be my responsibility to notify the _user_ that they've entered a bad query, but it might be my responsibility to notify an _admin_ in the case of a missing index. On 8 May 2015 at 01:03, David Pilato [david@pilato.fr](mailto:david@pilato.fr) wrote: > Indeed. The only workaround I can see in addition to the one you found > with + is to set `default_operator` to `AND` > > DELETE simple > PUT simple/test/1 > { > "foo": "bar baz" > } > PUT simple/test/2 > { > "foo": "bar boz" > } > GET simple/\_search > { > "query": { > "simple\_query\_string": { > "query": "bar baz", > "fields": ["foo"], > "default\_operator": "AND" > } > } > } > > But that’s not exactly what you are looking for. > > -- > _David Pilato_ - Developer | Evangelist > _[elastic.co](http://elastic.co) [http://elastic.co](http://elastic.co)_ > @dadoonet [https://twitter.com/dadoonet](https://twitter.com/dadoonet) | @elasticsearchfr > [https://twitter.com/elasticsearchfr](https://twitter.com/elasticsearchfr) | @scrutmydocs > [https://twitter.com/scrutmydocs](https://twitter.com/scrutmydocs) > > Le 7 mai 2015 à 07:41, Jason [snixtor@gmail.com](mailto:snixtor@gmail.com) a écrit : > > _"I think that AND might work as well with simple query string"_ > > Tried just now. Doesn't work, it gets treated as a search term instead of > an operator, so is functionally equivalent to "and" in query\_string. I > _could_ try translating operators, but a truly robust implementation of > that is more work than I would have liked. > > On 7 May 2015 at 15:35, David Pilato [david@pilato.fr](mailto:david@pilato.fr) wrote: > > > No that's fine to keep this thread here. > > Well with query\_string you can also use + > > > > I did not check but I think that AND might work as well with simple query > > string. It's not? > > > > David > > > > Le 7 mai 2015 à 07:14, Snixtor [snixtor@gmail.com](mailto:snixtor@gmail.com) a écrit : > > > > Regarding the discussion forum, I noticed literally 1 minute after > > posting this message. Should I duplicate this question in the forum? Can it > > be moved from the discussion group into the forum? The "we have moved" FAQ > > didn't address this matter of "transition". > > > > Regarding simple\_query\_string, I'm not as fond of the syntax. My > > application is transitioning from another text search system to > > Elasticsearch, and the syntax of query\_string is a closer match to what > > users are familiar with. For example, query\_string uses "AND", while > > simple\_query\_string uses "+". For the user base, that's possibly a > > _bigger_ issue than big error messages. > > > > On Thursday, 7 May 2015 15:01:55 UTC+10, David Pilato wrote: > > > > > Try simple\_query\_string. > > > > > > BTW we moved to [https://discuss.elastic.co/](https://discuss.elastic.co/) > > > > > > David > > > > > > Le 7 mai 2015 à 06:56, Snixtor [sni...@gmail.com](mailto:sni...@gmail.com) a écrit : > > > > > > I have an application allowing users to specify the "query" value of a > > > "query\_string" query. If the user inputs invalid search syntax, e.g. their > > > search is only "AND" (an operator without any values), Elasticsearch > > > returns an _exceedingly_ verbose error message with very > > > user-unfriendly text like "failed to execute phase" and "shard failure", > > > when what I really want is a simple user-friendly error like "Bad search > > > syntax". In this particular example, text within the > > > "QueryParsingException" sections is close to what I'm looking for. > > > > > > QueryParsingException[[\] Failed to parse query [AND]] > > > > > > But it's buried in a sea of text. I could parse out any text within the > > > QueryParsingException, but frankly that feels like reverse-engineering. Will > > > _all_ queries with bad syntax have user-friendly error text like this > > > particular example? Is the most user-friendly message always likely to > > > appear within QueryParsingException? Are there other error scenarios I > > > might want to handle that don't even have a QueryParsingException? > > > > > > I've been digging through Elasticsearch documentation for some > > > explanation of the kinds of errors I might expect and what format those > > > error messages will be in, but I'm coming up blank. For what it's worth, > > > I'm integrating using the .NET client _NEST_. > > > > > > ## -- Please update your bookmarks! We moved to [https://discuss.elastic.co/](https://discuss.elastic.co/) > > > > > > You received this message because you are subscribed to the Google > > > Groups "elasticsearch" group. > > > To unsubscribe from this group and stop receiving emails from it, send > > > an email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > To view this discussion on the web visit > > > [https://groups.google.com/d/msgid/elasticsearch/94d494a5-9d97-4ace-ab6a-7ba9d1f05734%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/94d494a5-9d97-4ace-ab6a-7ba9d1f05734%40googlegroups.com) > > > [https://groups.google.com/d/msgid/elasticsearch/94d494a5-9d97-4ace-ab6a-7ba9d1f05734%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/94d494a5-9d97-4ace-ab6a-7ba9d1f05734%40googlegroups.com?utm_medium=email&utm_source=footer) > > > . > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > ## -- Please update your bookmarks! We moved to [https://discuss.elastic.co/](https://discuss.elastic.co/) > > > > You received this message because you are subscribed to the Google Groups > > "elasticsearch" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > > To view this discussion on the web visit > > [https://groups.google.com/d/msgid/elasticsearch/c4cfd193-ae36-44fe-bb94-aad0dd374c5d%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/c4cfd193-ae36-44fe-bb94-aad0dd374c5d%40googlegroups.com) > > [https://groups.google.com/d/msgid/elasticsearch/c4cfd193-ae36-44fe-bb94-aad0dd374c5d%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/c4cfd193-ae36-44fe-bb94-aad0dd374c5d%40googlegroups.com?utm_medium=email&utm_source=footer) > > . > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > > > ## -- Please update your bookmarks! We moved to [https://discuss.elastic.co/](https://discuss.elastic.co/) > > > > You received this message because you are subscribed to a topic in the > > Google Groups "elasticsearch" group. > > To unsubscribe from this topic, visit > > [https://groups.google.com/d/topic/elasticsearch/CSmm9zdw1dM/unsubscribe](https://groups.google.com/d/topic/elasticsearch/CSmm9zdw1dM/unsubscribe). > > To unsubscribe from this group and all its topics, send an email to > > [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > > To view this discussion on the web visit > > [https://groups.google.com/d/msgid/elasticsearch/E18DB6FC-7FA1-4A84-AC73-D80113AD19FB%40pilato.fr](https://groups.google.com/d/msgid/elasticsearch/E18DB6FC-7FA1-4A84-AC73-D80113AD19FB%40pilato.fr) > > [https://groups.google.com/d/msgid/elasticsearch/E18DB6FC-7FA1-4A84-AC73-D80113AD19FB%40pilato.fr?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/E18DB6FC-7FA1-4A84-AC73-D80113AD19FB%40pilato.fr?utm_medium=email&utm_source=footer) > > . > > > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > ## -- Please update your bookmarks! We moved to [https://discuss.elastic.co/](https://discuss.elastic.co/) > > You received this message because you are subscribed to the Google Groups > "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > To view this discussion on the web visit > [https://groups.google.com/d/msgid/elasticsearch/CANsC95qnEtcfTORTs%3DFq-qSuHFn3-eeEiv2UC36HLq12eHsv1Q%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CANsC95qnEtcfTORTs%3DFq-qSuHFn3-eeEiv2UC36HLq12eHsv1Q%40mail.gmail.com) > [https://groups.google.com/d/msgid/elasticsearch/CANsC95qnEtcfTORTs%3DFq-qSuHFn3-eeEiv2UC36HLq12eHsv1Q%40mail.gmail.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/CANsC95qnEtcfTORTs%3DFq-qSuHFn3-eeEiv2UC36HLq12eHsv1Q%40mail.gmail.com?utm_medium=email&utm_source=footer) > . > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). > > ## -- Please update your bookmarks! We moved to [https://discuss.elastic.co/](https://discuss.elastic.co/) > > You received this message because you are subscribed to a topic in the > Google Groups "elasticsearch" group. > To unsubscribe from this topic, visit > [https://groups.google.com/d/topic/elasticsearch/CSmm9zdw1dM/unsubscribe](https://groups.google.com/d/topic/elasticsearch/CSmm9zdw1dM/unsubscribe). > To unsubscribe from this group and all its topics, send an email to > [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > To view this discussion on the web visit > [https://groups.google.com/d/msgid/elasticsearch/1C955DCD-6E33-443D-8292-2FD79ADCC567%40pilato.fr](https://groups.google.com/d/msgid/elasticsearch/1C955DCD-6E33-443D-8292-2FD79ADCC567%40pilato.fr) > [https://groups.google.com/d/msgid/elasticsearch/1C955DCD-6E33-443D-8292-2FD79ADCC567%40pilato.fr?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/1C955DCD-6E33-443D-8292-2FD79ADCC567%40pilato.fr?utm_medium=email&utm_source=footer) > . > > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ## -- Please update your bookmarks! We moved to [https://discuss.elastic.co/](https://discuss.elastic.co/) You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CANsC95qOv5W%2BKJzhUTdHO49AQ8490ETcEiL3da6bQws5MG8eCg%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CANsC95qOv5W%2BKJzhUTdHO49AQ8490ETcEiL3da6bQws5MG8eCg%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![Snixtor](https://avatars.discourse-cdn.com/v4/letter/s/f08c70/32.png) [@Snixtor](https://discuss.elastic.co/u/Snixtor)\ **Post date:** [May 12, 2015, 1:14am UTC](https://discuss.elastic.co/t/error-handling-for-http-search-api/23583/8 "2015-05-12T01:14:18Z")
So I'm still none-the-wiser. It feels like this is a notable omission in the Elasticsearch implementation. I _want_ to implement more graceful error handling for my Elasticsearch integration, but the means don't seem to be available. Is this the case? The deeper I consider the situation, the further it goes beyond simple query validation, that's just a single simple example. Scenario: 1. User sends a query to my application. 2. My application sends the query to ES. 3. ES returns an error to my application. 4. My application processes detail of the error and provides a suitable message to the user, such as: a) Your query was badly formed, try again. b) The index doesn't exist. c) The iron-man node is failing. d) The server is on fire, please call 911. But I can't do this, because I can't find any specification of the types of error messages that ES might return, or what structure they are in so I can reliably parse the content. How do I know the error message won't come back in XML, or even image/jpeg? I know that's an absurd example, but without spec... ## -- Please update your bookmarks! We have moved to [https://discuss.elastic.co/](https://discuss.elastic.co/) You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/595e377a-0f58-4111-b860-b0f854c66526%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/595e377a-0f58-4111-b860-b0f854c66526%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 12:14am UTC](https://discuss.elastic.co/t/error-handling-for-http-search-api/23583/9 "2017-07-06T00:14:31Z")