Íñigo Goiri commented on HDFS-13435:

Thanks [~linyiqun].
Most times, I left the full exception with the full stack trace if the error is 
not known, for example in {{NamenodeHeartbeatService}}:
} catch (Exception e) {
  LOG.error("Cannot get stat from {} using JMX", getNamenodeDesc(), e);
} catch(Throwable e) {
  // Generic error that we don't know about
  LOG.error("Unexpected exception while communicating with {}: {}",
      getNamenodeDesc(), e.getMessage(), e);
In these cases, the exception might not be enough to figure out where this came 
That being said, I agree that this is the right practice and the more stable 
RBF is, the less we would need these tricks.

Another issue, is the use of a dot at the end of the log messages.
You went pretty consistent (except for {{NamenodeHeartbeatService}}) with 
adding a dot at the end, but not sure this is the standard practice.
>From other parts of the code, there are examples of both; I would personally 
>skip the dot.

> RBF: Fix wrong error loggings
> -----------------------------
>                 Key: HDFS-13435
>                 URL: https://issues.apache.org/jira/browse/HDFS-13435
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>    Affects Versions: 3.0.1
>            Reporter: Yiqun Lin
>            Assignee: Yiqun Lin
>            Priority: Major
>         Attachments: HDFS-13435.001.patch
> There are many places that using {{Logger.error(String format, Object... 
> arguments)}} incorrectly.
>  A example:
> {code:java}
> LOG.error("Cannot remove {}", path, e);
> {code}
> The exception passed here is no meaning and won't be printed. Actually it 
> should be update to
> {code:java}
> LOG.error("Cannot remove {}: {}.", path, e.getMessage());
> {code}
> or 
> {code:java}
> LOG.error("Cannot remove " +  path, e));
> {code}

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org

Reply via email to