在hadoop2.2.0（hadoopcommon）中，我看到以下签名和文档 FileUtil.copy :
/**Copy files between FileSystems. */
public static boolean copy(FileSystem srcFS, Path src,
FileSystem dstFS, Path dst,
boolean deleteSource,
Configuration conf) throws IOException {我该怎么解释呢 boolean 同时 IOException ? 它是为了区分两类可能的错误，基于对错误的具体理解吗 IOException ?
在源代码中， false 已使用 if (!dstFS.mkdirs(dst)) 但是 IOException 被抛出 if (!dstFS.exists(dst)) （例如）。
通常的做法是同时返回状态值和抛出异常吗？处理这两个问题的客户端代码变得很麻烦。。。
1条答案
按热度按时间zte4gxcn1#
这种方法在apachehadoop的历史上非常古老。方法签名风格至少可以追溯到2006年，当时项目从apachenutch分离出来。
https://github.com/apache/hadoop-common/blob/9d5bba827967a12bf6182029235df46645eb4264/src/java/org/apache/hadoop/fs/fileutil.java
（方法名称不同，但签名遵循相同的样式。）
在我们的开发历史中，我找不到任何关于方法签名样式的具体讨论。我认为一个公平的理论是，这遵循了jdk中类似的约定
File应用程序编程接口。这个boolean返回值与基础mkdirs或者delete操作失败。同样地，java.io.File#delete以及java.io.File#mkdirs使用boolean返回通信失败的代码。hadoop方法很可能遵循这种风格，然后还使用IOException对于其他逻辑错误和真正的i/o错误，例如无法建立到远程守护程序（如namenode）的网络连接。我不会说这种风格的方法签名是常见的做法或良好的做法。正如您所说，它使客户机代码的错误处理复杂化。jdk7似乎已经认识到了使用
boolean返回这些操作的代码，因为它无法区分失败的具体原因。在Java7中启动的nio文件api中的等效方法，例如java.nio.file.Files#delete以及java.nio.file.Files#createDirectory，而选择使用特定的异常类型来报告不同情况下的错误（并删除了boolean返回）。ApacheHadoop社区最近讨论了如何为我们自己的api设计效法。由于向后兼容性的原因，当前的方法签名不太可能更改，即使是更好的。我们可以根据自己的需求，在主要版本边界上修改它
Compatibility但这将是一个挑战。