Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rest client's synchronous APIs throw less than useful exceptions #28399

Closed
nik9000 opened this issue Jan 26, 2018 · 0 comments
Closed

Rest client's synchronous APIs throw less than useful exceptions #28399

nik9000 opened this issue Jan 26, 2018 · 0 comments
Assignees
Labels
:Clients/Java Low Level REST Client Minimal dependencies Java Client for Elasticsearch >feature

Comments

@nik9000
Copy link
Member

nik9000 commented Jan 26, 2018

The Java rest client's synchronous calls throw exceptions in "funny" ways that seem to come with all the disadvantages of async code. When they throw an exception they only have the stack trace from the innards of the http-async client and they don't get decorated with suppressed exceptions if thrown from inside of a finally block. This makes debugging failures difficult and I'm going to look into fixing it.

@nik9000 nik9000 added the :Clients/Java Low Level REST Client Minimal dependencies Java Client for Elasticsearch label Jan 26, 2018
@nik9000 nik9000 self-assigned this Jan 26, 2018
nik9000 added a commit to nik9000/elasticsearch that referenced this issue Mar 7, 2018
In the past the Low Level REST Client was super careful not to wrap
any exceptions that it throws from synchronous calls so that callers can
catch the exceptions and work with them. The trouble with that is that
the exceptions are originally thrown on the async thread pool and then
transfered back into calling thread. That means that the stack trace of
the exception doesn't have the calling method which is *super* *ultra*
confusing.

This change always wraps exceptions transfered from the async thread
pool so that the stack trace of the thrown exception contains the
caller's stack. It tries to preserve the type of the throw exception but
this is quite a fiddly thing to get right. We have to catch every type
of exception that we want to preserve, wrap with the same type and
rethrow. I've preserved the types of all exceptions that we had tests
mentioning but no other exceptions. The other exceptions are either
wrapped in `IOException` or `RuntimeException`.

Closes elastic#28399
nik9000 added a commit that referenced this issue Mar 16, 2018
In the past the Low Level REST Client was super careful not to wrap
any exceptions that it throws from synchronous calls so that callers can
catch the exceptions and work with them. The trouble with that is that
the exceptions are originally thrown on the async thread pool and then
transfered back into calling thread. That means that the stack trace of
the exception doesn't have the calling method which is *super* *ultra*
confusing.

This change always wraps exceptions transferred from the async thread
pool so that the stack trace of the thrown exception contains the
caller's stack. It tries to preserve the type of the throw exception but
this is quite a fiddly thing to get right. We have to catch every type
of exception that we want to preserve, wrap with the same type and
rethrow. I've preserved the types of all exceptions that we had tests
mentioning but no other exceptions. The other exceptions are either
wrapped in `IOException` or `RuntimeException`.

Closes #28399
nik9000 added a commit that referenced this issue Mar 17, 2018
In the past the Low Level REST Client was super careful not to wrap
any exceptions that it throws from synchronous calls so that callers can
catch the exceptions and work with them. The trouble with that is that
the exceptions are originally thrown on the async thread pool and then
transfered back into calling thread. That means that the stack trace of
the exception doesn't have the calling method which is *super* *ultra*
confusing.

This change always wraps exceptions transferred from the async thread
pool so that the stack trace of the thrown exception contains the
caller's stack. It tries to preserve the type of the throw exception but
this is quite a fiddly thing to get right. We have to catch every type
of exception that we want to preserve, wrap with the same type and
rethrow. I've preserved the types of all exceptions that we had tests
mentioning but no other exceptions. The other exceptions are either
wrapped in `IOException` or `RuntimeException`.

Closes #28399
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Clients/Java Low Level REST Client Minimal dependencies Java Client for Elasticsearch >feature
Projects
None yet
Development

No branches or pull requests

1 participant