1

これは、どのような場合でも例外をスローしたくないパブリック メソッドです。この例では、例外がスローされるケースを確認できません (何か足りないのでしょうか?)。この場合の BKM は何ですか? これは好みの問題ですか？または、そのような場合のガイドラインがあります。

    public IEnumerable<DataEnumerable.Column> GetCollectionSchema(string collectionName)
    {
        // Is this try catch block redundant?
        try
        {
            if (CoordinationDataCollection != null)
            {
                var collection = CoordinationDataCollection.FirstOrDefault(x => x.CollectionName == collectionName);

                if (collection != null)
                {
                    return collection.Schema;
                }
            }
        }
        catch(Exception ex)
        {
            _log.Error("Error occurred while trying to get collection schema", ex);
        }

        return new List<DataEnumerable.Column>();
    }
4

4 に答える 4

2

パブリック メソッドが例外的なケースで例外をスローしても問題ありません。これらが文書化されている限り、問題ないはずです。

あなたの例でCoordinationDataCollectionはnull、それがそうである場合、例外がスローされます。

潜在的な例外を抑制するよりも、それらを文書化するか、例外を発生させ、呼び出し元が何をすべきかを決定できるようにする方がよい場合があります。

上記は単なる例です。他の多くのことがうまくいかない可能性があります。

于 2013-09-23T10:08:22.127 に答える
1

まず、パブリック メソッドはその入力パラメーターを検証する必要があります。

Contract.Requires(!string.IsNullOrEmpty(collectionName));

2 番目のこと: コードで予測される種類の例外のみをキャッチする必要があります。言い換えれば、投稿したメソッドは catch すべきではありませんException。なぜなら、呼び出し元の観点からは、メソッドが空のコレクションを返した理由が明確ではないためです。実際に空であるか、例外が発生するかのいずれかです。

于 2013-09-23T10:46:56.373 に答える
1

たとえば、この場合に考えなければならないことは、更新時に DataCollection ファイルが変更され、フィールドが変更された場合にどうなるかということCollectionNameです。または、データベースへの接続が利用できない場合はどうなりますか。

これは、そのようなコードを単純化するときに try catch でチェックしているものです。コードが失敗しないことがわかっています。キャッチは、予期しない問題、つまり例外をキャッチすることです。

于 2013-09-23T10:08:13.943 に答える