Error handling with native vs REST API (and order of application of connection opts)

22 views
Skip to first unread message

Steve Davis

unread,
Jan 15, 2016, 5:09:53 PM1/15/16
to clojure-elasticsearch
When a document is submitted to Elasticsearch and it doesn't match the relevant mapping, there appear to be some inconsistencies with how the errors are handled in elastisch's native vs REST APIs.  The native API throws an exception on document `put` and `create` (ns:  clojurewerkz.elastisch.native.document).  However, the REST API will only throw an exception on document `create` but doesn't throw an exception on `put` (ns: clojurewerkz.elastisch.rest.document).  Instead of throwing an exception on `put`, it returns a map with `:status` and `:error` keys.

To make the usage of the native and rest document actions more consistent, I tried setting the `:throw-exceptions` option in the connection config opts to make the REST `put` also throw exceptions, but it doesn't appear to work.  It looks like the `:throw-exceptions` option isn't able to be overridden by connection config opts.  

For example, the default for `:throw-exceptions` is set here to `false`:
https://github.com/clojurewerkz/elastisch/blob/master/src/clojurewerkz/elastisch/rest.clj#L33

And it merges the connection config opts _before_ applying the default (:const) for `:throw-exceptions`, which essentially means it is unable to use anything but the default here:
https://github.com/clojurewerkz/elastisch/blob/master/src/clojurewerkz/elastisch/rest.clj#L53-L54

I think if the opts are merged last rather than the defaults, then we would be able to get our desired result, which is throwing exceptions upon `put` and `create` errors (just like the native API).  Does that make sense?

Thanks,
Steve

Avi Flax

unread,
Apr 14, 2016, 9:29:15 PM4/14/16
to clojure-elasticsearch
Makes sense to me! I have similar concerns, and I’ve been puzzled to see that it’s not possible to override :throw-exceptions — and also that the var is used for its value is permanently set to false _and_ is a const! There must be some reason for all this strictness but I have yet to discern it.
Reply all
Reply to author
Forward
0 new messages