Hi all,
I hope this email finds you well.
We are a team working on a Java exception-related bug detection tool, and
recently we conducted a systematic analysis of exception handling logic across
Hadoop-3.3.6 modules including Common, YARN, MapReduce, and HDFS.
During the analysis, we identified a recurring issue that we believe is worth
discussing with the community: in many code locations, caught exceptions are
rethrown as new exceptions without propagating the original exception as the
root cause. This practice leads to swallowed root causes and incomplete stack
traces in error reports, which significantly hinders troubleshooting efforts
for developers and users.
Example Issue in HDFS
A typical case of this issue is found in the class
org.apache.hadoop.hdfs.qjournal.client.QuorumJournalManager (Hadoop-3.3.6) at
multiple code blocks, such as lines 257-261:
```java
try { call.waitFor(loggers.size(), loggers.size(), 0, timeoutMs, "format"); }
catch (InterruptedException e) { throw new IOException("Interrupted waiting for
format() response");//no cause } catch ( TimeoutException e) { throw new
IOException("Timed out waiting for format() response");//no cause }
```
In the above code, when InterruptedException or TimeoutException is caught, a
new IOException is thrown but the original exception (e) is not passed as the
cause parameter. As a result, the stack trace of the root cause is lost, making
it impossible to trace the exact origin of the failure.
Proposed Fix
The fix for this issue is straightforward and non-intrusive: pass the original
exception as the cause when constructing the new exception, which preserves the
complete stack trace context. For the example above, the corrected code would
be:
```java
try { call.waitFor(loggers.size(), loggers.size(), 0, timeoutMs, "format"); }
catch (InterruptedException e) { throw new IOException("Interrupted waiting for
format() response", e); } catch (TimeoutException e) { throw new
IOException("Timed out waiting for format() response", e); }
```
Multiple code blocks in QuorumJournalManager.java are affected (lines: 257-261,
275-279, 682-686, 699-703, 716-720, 747-753, 768-772, 785-791, 816-822),for
detailed information, please refer to the ticket I filed:
https://issues.apache.org/jira/browse/HDFS-17869
Scope of the Issue
We have identified similar issues in multiple Hadoop modules:
Hadoop-Common, HDFS , YARN, MapReduce: A number of classes with exception
handling logic that does not propagate root causes
Community Discussion Points
We would like to solicit the community's opinions on the following points:
1.Do you think fixing these exception cause loss issues is meaningful for
improving Hadoop's debuggability and user experience?
2.If the community agrees this is a valid improvement, we plan to:
- Create a set of JIRA tickets (one parent ticket + subsystem-specific
sub-tickets) to track all these fixes. (to avoid overloading the JIRA system)
- Submit targeted patches for each affected subsystem
- Ensure all changes comply with Hadoop's coding standards
We appreciate your time and feedback on this matter. Please let us know your
thoughts.
Thanks，
LinJin Wei
[email protected]
