belugabehr commented on code in PR #3478:
URL: https://github.com/apache/hive/pull/3478#discussion_r933556524
##########
standalone-metastore/metastore-common/src/main/java/org/apache/hadoop/hive/metastore/ReplChangeManager.java:
##########
@@ -205,7 +205,7 @@ private ReplChangeManager(Configuration conf) throws
MetaException {
inited = true;
}
} catch (IOException e) {
- throw new MetaException(StringUtils.stringifyException(e));
+ throw new MetaException(e.getMessage());
Review Comment:
I completely agree with everything you have put forward here. Checkout out.
HIVE-25126.
I do not think however it is such a burden to log-and-throw for now,... with
the end goal of removing it completely. I think adding a utility work-around
like this is not ideal in an open-source project because it becomes yet another
little thing everyone needs to be aware of, whereas log-and-throw is a much
more natural (albeit anti-pattern) behavior.
So to summarize my position:
Yes. Should remove all references to MetaException within the core Hive
product. It should only exists as a log-and-throw at the top-level service
level. It should contain a helpful message for the client in order to respond
appropriately to the error condition, and the details (i.e., complete
stacktrace) should be logged on the server. This will making debugging much
more consistent. There have been many times I have been stumped because the
stack trace prints on the client side, and just a small message (or nothing at
all) appears in the server logs. It's also confusing because I'm never sure at
first if the stacktrace presented on the client side occurred within the server
or within the client itself.
Yes. Sending internal stack traces to external clients is a security risk
Yes. `StringUtils.stringifyException` is duplicative of what SLF4J offers
and should be removed completely.
Yes. I think we should push through this PR and I can do some more of this
work by the same parameters discussed here. Just waiting on your `+1` :)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
