0

別のWindowsサーバーからディレクトリとファイルの合計バイト数を取得していますが、これら2つの方法でtry catchブロックが必要かどうかわかりませんか？助けてください

private void retrieveTotalBytes(File sourceFile)
{
    File[] files = sourceFile.listFiles();
    for(File file : files)
    {
        if(file.isDirectory()) 
            retrieveTotalBytes(file);
        else totalBytes += file.length();
    }
}

private void copyFiles(File sourceFile, File targetFile) throws IOException
{
    if(sourceFile.isDirectory())
    {
        if(!targetFile.exists()) targetFile.mkdirs();

        String[] filePaths = sourceFile.list();
        for(String filePath : filePaths)
        {                                 
            File srcFile = new File(sourceFile, filePath);
            File destFile = new File(targetFile, filePath);

            copyFiles(srcFile, destFile);
        }
    }
    else
    { }
}
4

2 に答える 2

2

これらの関数は低いので、内部に入れる必要はないと思います（クライアントがこれらの責任ある決定を行うのに十分賢いと仮定します）。しかし、これらの関数を呼び出すより高いレベルでそれを行うことを検討するかもしれません。

例えば ​​。。。

File data, destination;

try { copyFiles(data, destination); }
catch (IOException e) { . . . }


// and. . .

try { retrieveTotalBytes(data); }
catch (Exception e) { . . . };

。。。しかし、それはあなた次第です

于 2012-12-25T01:15:00.197 に答える
1

いくつかの選択肢があります。

1）キャッチアンドハンドル（この低レベルでのロギングの必要性を生み出します）。

これは、エラーがコードの操作に関係がない場合にのみ実際に解決策になります（おそらくそうではありません）

2）アプリケーション固有の例外としてキャッチして再スローします。

これにより、「ApplicationException」ツリー内に例外を構築し、他の例外と一緒にキャッチすることができます。

3）RuntimeExceptionとしてキャッチして再スローします。

おそらく、ファイルが読み取り可能であること、ディレクトリが管理可能であることなどを確認するためにすべてのチェックをすでに実行しているため、エラーをスローする実際的な理由はありません。スローした場合、回復できない場合があります。それができない場合は、スタックの一番上まで「IOException」をスローすることになりますが、これはばかげています。

代わりに、この「回復不能」をRuntimeExceptionとして再スローして、非常に高いレベルでキャッチし、ダイアログボックスを開いてクラッシュすることができます。

4）プレーンIO例外をスローし、問題をチェーンに渡します。

これは問題を解決するものではなく、単にアプリケーションを上に移動するだけです（そして、IOExceptionがコードベースにブリードできるようにします）。

于 2012-12-25T01:42:44.080 に答える