# Possible error return values

**URL:** <https://discuss.elastic.co/t/possible-error-return-values/3857>\
**Category:** Elasticsearch\
**Created:** [February 1, 2011, 12:24pm UTC](https://discuss.elastic.co/t/possible-error-return-values/3857 "2011-02-01T12:24:27Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![rboulton](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/rboulton/32/3271_2.png) [@rboulton](https://discuss.elastic.co/u/rboulton)\
**Post date:** [February 1, 2011, 12:24pm UTC](https://discuss.elastic.co/t/possible-error-return-values/3857/1 "2011-02-01T12:24:27Z")

</div>

Quick question; is there a list of all possible error return values?  
ideally, a list of the HTTP status codes and a description of what the  
returned JSON contains, but any information would be helpful.

Why am I asking? I'm looking into using elasticsearch for a project  
which is built in python. pyes looks to be the best python client,  
but it's current error handling works by following the algorithm:

- if 'ok' is in the result, it's not an error, so return it.
- if 'error' is in the result, look at its contents, and do string  
pattern matching on them. Some patterns in the contents, with some  
combinations of HTTP status codes 400 or 500, will cause an exception  
to be raised.
- if no patterns are matched, pyes will print the error contents to  
stdout (!) and the just return them to the caller.

I'd like to improve this, and will start by making a generic exception  
for unrecognised error contents, but it would be nice to be able to be  
comprehensive in mapping possible error return values to appropriate  
python exceptions.

It would be even nicer if elasticsearch produced a structured error  
output, with a field containing the error type, and another field  
containing any message which should be associated with the error, so  
that string pattern matching didn't need to be used. (If there's an  
option to turn that on, please let me know, it'd be lovely!)

---

<div class="post-metadata">

**Author:** ![rboulton](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/rboulton/32/3271_2.png) [@rboulton](https://discuss.elastic.co/u/rboulton)\
**Post date:** [February 1, 2011, 2:18pm UTC](https://discuss.elastic.co/t/possible-error-return-values/3857/2 "2011-02-01T14:18:50Z")

</div>

I've just chatted to kimchy on IRC about this, so for posterity I'll  
reply to my own message with the information gleaned:

- There's no simple list of error values.
- The possible error results are specific to each operation.
- Most errors will return 400 or 500 status codes, but some other  
codes are used (eg, 409 (CONFLICT) for a conflict in versions when  
indexing).

I've just been grubbing through the code, and I think I'm correct to  
say that error responses will always be an object with an "error"  
property containing the status message, so this is probably the best  
way to check for an error response.

For client writing, I think it would be lovely if error responses  
could have a property added to them with the classname of the Java  
exception which was raised, so that a client could define a mapping to  
an appropriate exception in the client language. As a start, doing  
this for the exceptions which return 400 series error codes would  
probably be most tractable, since these tend to be picked out  
specially in the response generation code already. (eg at [http://goo.gl/yn4OV](http://goo.gl/yn4OV)  
)

--  
Richard Boulton

---

<div class="post-metadata">

**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, 4:12am UTC](https://discuss.elastic.co/t/possible-error-return-values/3857/3 "2017-07-06T04:12:58Z")

</div>