# How to handle ElasticSearch RestHighLevelClient exceptions properly?

**URL:** <https://discuss.elastic.co/t/how-to-handle-elasticsearch-resthighlevelclient-exceptions-properly/129502>\
**Category:** Elasticsearch\
**Created:** [April 25, 2018, 1:49pm UTC](https://discuss.elastic.co/t/how-to-handle-elasticsearch-resthighlevelclient-exceptions-properly/129502 "2018-04-25T13:49:36Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![cdekker](https://avatars.discourse-cdn.com/v4/letter/c/f05b48/32.png) [@cdekker](https://discuss.elastic.co/u/cdekker)\
**Post date:** [April 25, 2018, 1:49pm UTC](https://discuss.elastic.co/t/how-to-handle-elasticsearch-resthighlevelclient-exceptions-properly/129502/1 "2018-04-25T13:49:36Z")

</div>

What is the proper way to handle Exceptions when dealing with the ElasticSearch `RestHighLevelClient` introduced in 5.0? I am currently working with 6.1.

There have been some discussions on whether to use checked or unchecked exceptions ([https://github.com/elastic/elasticsearch/issues/19980](https://github.com/elastic/elasticsearch/issues/19980)) but it seems that the `RestHighLevelClient` still throws unchecked ElasticsearchExceptions. `ElasticsearchException` has many different subclasses and is a direct subclass of RuntimeException itself.

However, most straightforward methods like `client.search(..)` can also throw the checked exception `IOException`. ElasticSearch implements `ResponseException` as a subclass of `IOException` which is thrown, for example, in the `org.elasticsearch.client.RestClient`.

I figured, I'd catch this `IOException` to handle any ES error gracefully and be done with it, but this seems to be incorrect. During some invalid query (value for integer too large) this `ResponseException` is thrown, but somewhere inside ElasticSearch client **converted** to an unchecked `ElasticsearchException` which I didn't catch yet!

What is even worse, none of this exception handling seems to be documented in the otherwise excellent ES documentation: [https://www.elastic.co/guide/en/elasticsearch/client/java-rest/master/java-rest-high-search.html](https://www.elastic.co/guide/en/elasticsearch/client/java-rest/master/java-rest-high-search.html)

Right now, I basically have to write my own wrapper to handle all realistic exceptions, and do this for every client method I wish to use in my application. For example, this is my wrapper for `search`, the most common use case.

```
public SearchResponse search(String[] indexNames, String docType, SearchSourceBuilder source) throws MyESException {
	try {
		return client.search(new SearchRequest(indexNames).types(docType).source(source));
	} catch (IOException | ElasticsearchException e) {
		throw new MyESException(e);
	}
}

```

As you can see, this is quite ugly, having to handle the checked IOException and unchecked ElasticsearchException identically. I can't imagine this is the intended way for the Java API to be used like this. Am I overlooking some crucial part of the ES documentation that explains this in greater detail?

---

<div class="post-metadata">

**Author:** ![javanna](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/javanna/32/4698_2.png) [@javanna](https://discuss.elastic.co/u/javanna)\
**Post date:** [May 2, 2018, 7:21pm UTC](https://discuss.elastic.co/t/how-to-handle-elasticsearch-resthighlevelclient-exceptions-properly/129502/2 "2018-05-02T19:21:53Z")

</div>

See opened issue: [https://github.com/elastic/elasticsearch/issues/30334](https://github.com/elastic/elasticsearch/issues/30334) . We are currently discussing this there.

---

<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:** [May 30, 2018, 7:21pm UTC](https://discuss.elastic.co/t/how-to-handle-elasticsearch-resthighlevelclient-exceptions-properly/129502/3 "2018-05-30T19:21:54Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.