[
https://issues.apache.org/jira/browse/HDFS-14471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
eBugs in Cloud Systems updated HDFS-14471:
------------------------------------------
Description:
Dear HDFS developers, we are developing a tool to detect exception-related bugs
in Java. Our prototype has spotted the following {{throw}} statement whose
exception class and error message seem to indicate different error conditions.
Since we are not very familiar with HDFS's internal work flow, could you please
help us verify if this is a bug, i.e., will the callers have trouble handling
the exception, and will the users/admins have trouble diagnosing the failure?
Version: Hadoop-3.1.2
File:
HADOOP-ROOT/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSDirectory.java
Line: 1646-1651
{code:java}
try {
id = Long.parseLong(inodeId);
} catch (NumberFormatException e) {
throw new FileNotFoundException("Invalid inode path: " +
DFSUtil.byteArray2PathString(pathComponents));
}{code}
Reason: A {{FileNotFoundException}} means that a target file cannot be found.
However, the error message indicates that the path is malformed (instead of
well-formed but pointing to no file). Will this mismatch be a problem? For
example, will the callers try to handle other {{FileNotFoundException}}
accidentally (and incorrectly) handle the malformed path? Or, will users/admins
misled by the exception class name and wonder why the file is missing?
was:
Dear HDFS developers, we are developing a tool to detect exception-related bugs
in Java. Our prototype has spotted the following {{throw}} statement whose
exception class and error message seem to indicate different error conditions.
Since we are not very familiar with HDFS's internal work flow, could you please
help us verify if this is a bug, i.e., will the callers have trouble handling
the exception, and will the users/admins have trouble diagnosing the failure?
Version: Hadoop-3.1.2
File:
HADOOP-ROOT/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSDirectory.java
Line: 1646-1651
{code:java}
try {
id = Long.parseLong(inodeId);
} catch (NumberFormatException e) {
throw new FileNotFoundException("Invalid inode path: " +
DFSUtil.byteArray2PathString(pathComponents));
}{code}
Reason: A {{FileNotFoundException}} means that a target file cannot be found.
However, the error message indicates that the path is malformed (instead of
well-formed but pointing to no file). Will this mismatch be a problem? For
example, will the callers try to handle other {{FileNotFoundException}}
accidentally (and incorrectly) handle the malformed path? Or, will users/admins
misled by the error message and wonder why the file is missing?
> FSDirectory.resolveDotInodesPath() throws FileNotFoundException when the path
> is malformed
> ------------------------------------------------------------------------------------------
>
> Key: HDFS-14471
> URL: https://issues.apache.org/jira/browse/HDFS-14471
> Project: Hadoop HDFS
> Issue Type: Bug
> Reporter: eBugs in Cloud Systems
> Priority: Minor
>
> Dear HDFS developers, we are developing a tool to detect exception-related
> bugs in Java. Our prototype has spotted the following {{throw}} statement
> whose exception class and error message seem to indicate different error
> conditions. Since we are not very familiar with HDFS's internal work flow,
> could you please help us verify if this is a bug, i.e., will the callers have
> trouble handling the exception, and will the users/admins have trouble
> diagnosing the failure?
>
> Version: Hadoop-3.1.2
> File:
> HADOOP-ROOT/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSDirectory.java
> Line: 1646-1651
> {code:java}
> try {
> id = Long.parseLong(inodeId);
> } catch (NumberFormatException e) {
> throw new FileNotFoundException("Invalid inode path: " +
> DFSUtil.byteArray2PathString(pathComponents));
> }{code}
> Reason: A {{FileNotFoundException}} means that a target file cannot be found.
> However, the error message indicates that the path is malformed (instead of
> well-formed but pointing to no file). Will this mismatch be a problem? For
> example, will the callers try to handle other {{FileNotFoundException}}
> accidentally (and incorrectly) handle the malformed path? Or, will
> users/admins misled by the exception class name and wonder why the file is
> missing?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
