Hadoop FileUtil.copy Unterschrift

Question

In Hadoop 2.2.0 (Hadoop-common), sehe ich die folgende Signatur und doc für FileUtil.copy:

/** Copy files between FileSystems. */ 
public static boolean copy(FileSystem srcFS, Path src, 
          FileSystem dstFS, Path dst, 
          boolean deleteSource, 
          Configuration conf) throws IOException { 

Was soll ich diese boolean und gleichzeitigen IOException machen? Soll auf der Grundlage eines spezifischen Verständnisses von IOException zwischen zwei Klassen möglicher Fehler unterschieden werden?

Im Quellcode wird falseif (!dstFS.mkdirs(dst)) verwendet wird, aber IOExceptionif (!dstFS.exists(dst)) (zum Beispiel) geworfen.

Ist es allgemein üblich, einen Statuswert zurückzugeben und gleichzeitig eine Ausnahme auszulösen? Der Client-Code, um beide zu behandeln, wird umständlich ...

Answer 1

Diese Methode ist sehr alt in der Geschichte von Apache Hadoop. Der Stil der Methodensignatur reicht bis mindestens 2006 zurück, als das Projekt von Apache Nutch abgespalten wurde.

https://github.com/apache/hadoop-common/blob/9d5bba827967a12bf6182029235df46645eb4264/src/java/org/apache/hadoop/fs/FileUtil.java

(Der Name der Methode war anders, aber die Unterschrift folgte dem gleichen Stil.)

ich keine spezifische Diskussion des Verfahrens Stil in unserer Entwicklungsgeschichte finden konnten. Ich denke, eine faire Theorie ist, dass dies aus ähnlichen Konventionen in der JDK File API folgte. Der Rückgabewert boolean ist relevant für Fälle, in denen ein zugrunde liegender mkdirs oder delete-Vorgang fehlschlägt. In ähnlicher Weise verwenden java.io.File#delete und java.io.File#mkdirs einen boolean Rückkehrcode, um Fehler zu kommunizieren. Die Hadoop-Methode folgte höchstwahrscheinlich diesem Stil und verwendete dann auch IOException für zusätzliche Logikfehler und echte E/A-Fehler, z. B. Fehler beim Herstellen einer Netzwerkverbindung zu einem Remote-Daemon wie dem NameNode.

Ich würde nicht sagen, dass diese Art der Methodensignatur gängige Praxis oder gute Praxis ist. Wie Sie gesagt haben, erschwert dies die Fehlerbehandlung für den Client-Code. JDK 7 scheint die Schwäche der Verwendung eines Rückgabecodes boolean für diese Operationen erkannt zu haben, da er den spezifischen Grund für einen Fehler nicht unterscheiden kann. Äquivalente Methoden in der NIO-Datei-API, die in Java 7 gestartet wurde, z. B. java.nio.file.Files#delete und java.nio.file.Files#createDirectory, haben stattdessen die Verwendung bestimmter Ausnahmetypen für die Fehlerberichterstattung in verschiedenen Fällen gewählt (und die boolean Rückgabe gelöscht). In der Apache Hadoop Community wurde kürzlich darüber diskutiert, ob wir unseren eigenen API Designs folgen können.

Die aktuelle Methodensignatur wird sich aus Gründen der Abwärtskompatibilität wahrscheinlich nicht verbessern. Wir könnten möglicherweise entscheiden, es an einer größeren Versionsgrenze gemäß unserer Compatibility Richtlinie zu ändern, aber es wäre eine Herausforderung.