-
Notifications
You must be signed in to change notification settings - Fork 8.9k
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
HDFS-16702. MiniDFSCluster should report cause of exception in assertion error #4671
Conversation
🎊 +1 overall
This message was automatically generated. |
@ayushtkn @snmvaughan could you please review this PR? |
return Integer.toString(status) + ": " + message; | ||
String finalString = status + ": " + message; | ||
Throwable cause = getCause(); | ||
if (cause != null) { | ||
finalString = finalString + " : \n" + "cause: " + cause.getMessage(); | ||
} | ||
return finalString; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we changing the response string, I am not sure about the compatibility here.
The above javadoc says
String value does not include exception type, just exit code and message.
We shouldn't make prod level API changes for MiniDFSCluster
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just exit code and message
In a way, we are just improving the message by also including cause message if any cause is associated. I just thought it would be good improvement. We are still not including exception type
even with this patch as the Javadoc claims. Only if we print the cause itself, then we would have included exception type. WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But if you still think we should not include cause.getMessage() in addition to this.getMessage(), I can remove it. It's just that we would be able to include one more layer of message to the existing message if we can include cause.getMessage() as well, just a minor improvement.
The original identified problem wasn't about the message of the thrown error, but the lack of a stack trace as part of that exception. |
|
I understand, but I would like to know if improving the toString() is useful. If no, I will remove it from this PR. If yes, and if it should be done separately, we can do that as well. @ayushtkn @snmvaughan thoughts? |
The updated message looks like it could be useful. |
This message change and stuff I doubt can land up with compatibility issues if some downstream or so is asserting the string output and then this will lead to too much of noise. |
…n assertion error" This reverts commit 00eacc4.
Sounds reasonable @ayushtkn. Updated the PR. |
Hmm, there are two PR now linked to the Jira and both to trunk? @snmvaughan / @virajjasani |
Ah, didn't realize that. @snmvaughan you can get your PR merged if you would like, I just felt taking this up only because the Jira was not assigned to you by the time I raised PR, but anything is fine. All upto you :) |
💔 -1 overall
This message was automatically generated. |
Description of PR