4

これは、Javaでtry/catchを実装するためのより適切な手法と見なされます。

A：

Date lastMod = null;
BufferedReader inFile = null;
    try {
        inFile = new BufferedReader(new FileReader("C:\\Java\\settings.ini"));
        try {
            lastMod = new Date(Long.parseLong(inFile.readLine()));
        } catch (IOException e) {
            e.printStackTrace();
        }
    } catch(FileNotFoundException e) {
        e.printStackTrace();
    }

またはB：

Date lastMod = null;
BufferedReader inFile = null;
    try {
        inFile = new BufferedReader(new FileReader("C:\\Java\\settings.ini"));
        lastMod = new Date(Long.parseLong(inFile.readLine()));
    } catch (FileNotFoundException e) {
        e.printStackTrace();
    } catch (IOException e) {
        e.printStackTrace();
    }

また、try / catchブロックの後にBufferedReaderを使用する長いコードブロックを続けるのは間違っていますか、それともtry / catch内に長いコードブロックを含めることが望ましいですか？

例えば：

public static void main(String[] args) {
    Date lastMod = null;
    BufferedReader inFile = null;
    try {
        inFile = new BufferedReader(new FileReader("C:\\Java\\settings.ini"));
        lastMod = new Date(Long.parseLong(inFile.readLine()));
    } catch (FileNotFoundException e) {
        e.printStackTrace();
    } catch (IOException e) {
        e.printStackTrace();
    }
    //Long block of code using inFile
    inFile.readLine();
    inFile.close();

対：

public static void main(String[] args) {
    Date lastMod = null;
    BufferedReader inFile = null;
    try {
        inFile = new BufferedReader(new FileReader("C:\\Java\\settings.ini"));
        lastMod = new Date(Long.parseLong(inFile.readLine()));
        //Long block of code using inFile
        inFile.readLine();
    } catch (FileNotFoundException e) {
        e.printStackTrace();
    } catch (IOException e) {
        e.printStackTrace();
    } finally {
        inFile.close();
    }
4

3 に答える 3

1

内部のtryブロックの後、外部のtryブロックの前に何も起こっていない場合、Bははるかに読みやすくなります。間に実行するロジックがある場合は、Aを使用する必要があります

2番目の例では、finallyを使用する2番目のバージョンは、（関数が最初に戻った場合でも）closeが呼び出されるようにするために重要です。finallyがない最初のバージョンは、すべてのファイルハンドルを使い果たして、使用できない可能性があるため、実際には間違っています。より多くのファイルを開きます。

追記として、closeを呼び出すときにnullをチェックする必要がある場合があります。また、Java 7を使用している場合は、「リソースで試す」を使用することをお勧めします。

于 2013-03-08T04:24:24.630 に答える
1

最初の質問: 解決策 A は不必要な複雑さを追加します。B を使用するか、Java 7 を使用している場合は try-with-resources を使用します。

    Date lastMod = null;
    try (BufferedReader inFile = new BufferedReader(new FileReader("C:\\Java\\settings.ini"))){
        lastMod = new Date(Long.parseLong(inFile.readLine()));
    } catch (FileNotFoundException | IOException e) {
        e.printStackTrace();
    }

2 番目の質問: 最初のバージョンで、BufferedReader作成時に例外がスローされた場合はどうなりますか? after which is null を使用するbrと、NullPointerException がスローされます。また、何か他のことが起こった場合、 を呼び出していないinFile.close()ので、本当に が必要ですfinally。これらすべての理由から、2 番目のソリューションの方が優れています。

もちろん、try-with-resouces (Java 7) を使用している場合は、BufferedReader を解放するために finally ブロックは必要ありません。

于 2013-03-08T04:27:08.120 に答える
0

適切な手法には、例外をキャッチするのではなく、代わりに呼び出し元にバブルアップできるようにすることも含まれる場合があります。リソースを使い果たす可能性のある状態をクリーンアップするために、常に finally ブロックを使用してください。

一般に、サブルーチンが成功したかどうかを呼び出し側ルーチンで知ることが役立つ場合、そのサブルーチンはその例外をキャッチするべきではありませんが、呼び出し元にバブルアップできるようにする必要があります。

于 2013-03-08T04:47:26.020 に答える