[
https://issues.apache.org/jira/browse/HADOOP-6345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12776047#action_12776047
]
Matt Ahrens commented on HADOOP-6345:
-------------------------------------
At a quick glance, i see 9 different paths....here they are with exit condition
and return value (or exception thrown):
1) interval set to 0 (trash feature disabled), EXIT: return false
2) path to move to trash doesn't exist, EXIT: FileNotFoundException
3) path to move to trash already in trash, EXIT: return false
4) path to move to trash contains trash path, EXIT: IOException
5) mkdirs() on base trash path fails, EXIT: return false
6) mkdirs() throws exception, EXIT: IOException
7) rename() throws exception, EXIT: IOException
8) rename() fails, EXIT: IOException
9) rename() succeeds, EXIT: return true
It might make sense to have only #1 return false and the others returning false
(#3, #5) instead return exceptions with specific info on failure cause.
> Refactor Trash::moveToTrash() and its accompanying poor tests
> -------------------------------------------------------------
>
> Key: HADOOP-6345
> URL: https://issues.apache.org/jira/browse/HADOOP-6345
> Project: Hadoop Common
> Issue Type: Improvement
> Components: fs
> Reporter: Jakob Homan
>
> We've had several issues relating to the Trash and its access via the shell,
> none of which were picked up by the unit tests. The current moveToTrash
> method has 8 different ways it can terminate and sometimes uses a false value
> and sometimes uses an exception to indicate failure. This method should be
> refactored to improve readability and testability, and new tests written to
> exercise all possible code paths.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
