[
https://issues.apache.org/jira/browse/HDFS-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
WeiLinJin updated HDFS-17869:
-----------------------------
Description:
Dear HDFS developers, we are developing a tool to detect exception-related bugs
in Java. Our primary focus is on identifying issues where the caught exception
is rethrown without propagating the original exception as the cause. When such
errors occur, the root cause exception is swallowed, resulting in incomplete
call stacks in error reports. This makes it hard to trace the origin of the
exception and hinders debugging efforts.
Version: Hadoop-3.3.6
File: org.apache.hadoop.hdfs.qjournal.client.QuorumJournalManager
Line: 257-261 275-279 682-686 699-703 716-720 747-753 768-772 785-791 816-822
For example，Line: 257-261:
{code: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
}
{code}
In the code snippet above, two key locations exhibit this problematic pattern:
when catching exceptions and re-throwing a new exception instance, the caught
original exceptions are not passed as the root cause (or "cause" parameter) of
the new exception. Without chaining the original exception to the new one, the
error stack trace loses critical context about the initial failure location,
which makes tracing the source of the original exceptions extremely difficult
and prolongs the troubleshooting process.
Fix Suggestion:
{code: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);
}
{code}
There are multiple instances of this issue in the methods of the
{{QuorumJournalManager.java}}. (257-261 275-279 682-686 699-703 716-720
747-753 768-772 785-791 816-822)
was:
Dear HDFS developers, we are developing a tool to detect exception-related bugs
in Java. Our primary focus is on identifying issues where the caught exception
is rethrown without propagating the original exception as the cause. When such
errors occur, the root cause exception is swallowed, resulting in incomplete
call stacks in error reports. This makes it hard to trace the origin of the
exception and hinders debugging efforts.
Version: Hadoop-3.3.6
File: org.apache.hadoop.hdfs.qjournal.client.QuorumJournalManager
Line: 257-261 275-279 682-686 699-703 716-720
For example，Line: 257-261:
{code: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
}
{code}
In the code snippet above, two key locations exhibit this problematic pattern:
when catching exceptions and re-throwing a new exception instance, the caught
original exceptions are not passed as the root cause (or "cause" parameter) of
the new exception. Without chaining the original exception to the new one, the
error stack trace loses critical context about the initial failure location,
which makes tracing the source of the original exceptions extremely difficult
and prolongs the troubleshooting process.
Fix Suggestion:
{code: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);
}
{code}
There are multiple instances of this issue in the methods of the
{{QuorumJournalManager.java}}. (Line: 257-261 275-279 682-686 699-703 716-720)
> Missing root exception cause in QuorumJournalManager.java
> ---------------------------------------------------------
>
> Key: HDFS-17869
> URL: https://issues.apache.org/jira/browse/HDFS-17869
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
> Affects Versions: 3.3.6
> Reporter: WeiLinJin
> Priority: Minor
> Labels: exception
>
> Dear HDFS developers, we are developing a tool to detect exception-related
> bugs in Java. Our primary focus is on identifying issues where the caught
> exception is rethrown without propagating the original exception as the
> cause. When such errors occur, the root cause exception is swallowed,
> resulting in incomplete call stacks in error reports. This makes it hard to
> trace the origin of the exception and hinders debugging efforts.
> Version: Hadoop-3.3.6
> File: org.apache.hadoop.hdfs.qjournal.client.QuorumJournalManager
> Line: 257-261 275-279 682-686 699-703 716-720 747-753 768-772 785-791 816-822
> For example，Line: 257-261:
> {code: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
> }
> {code}
> In the code snippet above, two key locations exhibit this problematic
> pattern: when catching exceptions and re-throwing a new exception instance,
> the caught original exceptions are not passed as the root cause (or "cause"
> parameter) of the new exception. Without chaining the original exception to
> the new one, the error stack trace loses critical context about the initial
> failure location, which makes tracing the source of the original exceptions
> extremely difficult and prolongs the troubleshooting process.
> Fix Suggestion:
> {code: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);
> }
> {code}
> There are multiple instances of this issue in the methods of the
> {{QuorumJournalManager.java}}. (257-261 275-279 682-686 699-703 716-720
> 747-753 768-772 785-791 816-822)
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
