Grant Henke has submitted this change and it was merged. ( 
http://gerrit.cloudera.org:8080/9610 )

Change subject: KUDU-2230: java: sync client exception stack traces should make 
sense
......................................................................

KUDU-2230: java: sync client exception stack traces should make sense

Previously the exceptions thrown by the synchronous client always had
a stack trace somewhere deep inside our async callback chain. So, when
the user eventually caught this exception, it would be very hard to even
know what part of their code failed, since their own code would not even
show up in the call chain.

This patch simply replaces the exception's stack trace with the stack at
the "join" point where the exception is transformed back to a
KuduException. An exception which stores the original stack trace is
attached as a "suppressed" exception.

Change-Id: I874d47b5239bcc8493c15ef763ecfe0fd878d795
Reviewed-on: http://gerrit.cloudera.org:8080/9489
Tested-by: Kudu Jenkins
Reviewed-by: Dan Burkert <danburk...@apache.org>
Reviewed-by: Alexey Serbin <aser...@cloudera.com>
(cherry picked from commit ce0db915787b58a79109e6faecc6f1daef9f2850)
Reviewed-on: http://gerrit.cloudera.org:8080/9610
Reviewed-by: Grant Henke <granthe...@gmail.com>
Tested-by: Grant Henke <granthe...@gmail.com>
---
M java/kudu-client/src/main/java/org/apache/kudu/client/KuduException.java
M 
java/kudu-client/src/test/java/org/apache/kudu/client/TestConnectToCluster.java
2 files changed, 30 insertions(+), 6 deletions(-)

Approvals:
  Grant Henke: Looks good to me, approved; Verified

--
To view, visit http://gerrit.cloudera.org:8080/9610
To unsubscribe, visit http://gerrit.cloudera.org:8080/settings

Gerrit-Project: kudu
Gerrit-Branch: branch-1.7.x
Gerrit-MessageType: merged
Gerrit-Change-Id: I874d47b5239bcc8493c15ef763ecfe0fd878d795
Gerrit-Change-Number: 9610
Gerrit-PatchSet: 2
Gerrit-Owner: Grant Henke <granthe...@gmail.com>
Gerrit-Reviewer: Grant Henke <granthe...@gmail.com>
Gerrit-Reviewer: Kudu Jenkins
Gerrit-Reviewer: Todd Lipcon <t...@apache.org>

Reply via email to