4

try-catch ステートメントでエラー処理を説明する適切な場所はどこですか? tryブロックやcatchブロックの先頭に説明コメントを入れてもいいようです。 

// Possible comment location 1
try
{   
    // real code
}
// Possible comment location 2
catch
{
    // Possible comment location 3

    // Error handling code

}
4

8 に答える 8

17

私は通常、次のことを行います。例外が 1 つしか処理されていない場合は、自己文書化する必要があるため、通常は気にしません。

try
{   
    real code // throws SomeException
    real code // throws SomeOtherException
}
catch(SomeException se)
{
    // explain your error handling choice if it's not obvious
}
catch(SomeOtherException soe)
{
    // explain your error handling choice if it's not obvious
}
于 2009-01-05T18:15:24.973 に答える
10

「コメントは嘘です」 . それらの変数名と一般的なロジックに取り組み、それを回避できるようにします。本当に嘘をつく必要がある場合は、catch ブロック内で行います。

于 2009-01-05T18:17:23.003 に答える
5

全然関係ないと思います。

コメントで覚えておくべき重要なことは、何よりもまず、コードが何をしているのかではなく、なぜコードがそのようになっているのかに対処することだと思います。これは、簡潔なコメントで複雑なロジックを説明するべきではないと言っているわけではありませんが、その理由は非常に重要です。

于 2009-01-05T18:12:53.293 に答える
4

余分なコメントが不要になるようにコードを設定するのはどうですか?

try
{ 
   performDifficultAct( parameter );
}
catch (ArgumentOutOfRangeException couldNotFindArgument)
{
   // handle exception
}
catch (Exception otherUnknownException )
{
   // handle exception
}

変数とメソッドの命名を使用して何が起こっているかを示すことができるかどうかを文書化する必要はありません。例外をログに記録したり発生させたりする必要があるかどうかを文書化する必要はありません。とにかく、ソース コードのログ メッセージは一目瞭然です。コードに追加のドキュメントが必要になるのは、コードが何をしているのかがまったく明らかでない場合、または追加しなければならない落とし穴やあいまいなステップが見逃されやすい場合のみです。今後のコード。

編集：少し明確にするために、これらの「キャッチ」ステートメントを使用して、メンテナンスプログラマーとユーザー/サポート/QA/ソフトウェアを使用する他の人の両方に役立つ情報を提供する方法をもう少し示します。また、コードにコメントを絶対に追加したい状況の例:

public void PerformSomeActionOrOther(string parameter)
{
  try
  { 
     // For some reason an eleven character string causes a bluescreen from Kernel32
     if (parameter.Length==11) parameter+=" ";

     performDifficultAct( parameter );
  }
  catch (ArgumentOutOfRangeException couldNotFindArgument)
  {
     this.Log.WriteLn("Argument out of range exception in ArbitraryClass.PerformSomeActionOrOther");
     this.Log.WriteLn(String.Format("Probable cause is that {0} is not in the array", parameter));
     this.Log.WriteLn(String.Format("Exception: {0}", couldNotFindArgument.Message));
  }
  catch (Exception otherUnknownException )
  {
     this.Log.WriteLn("Unexpected exception in ArbitraryClass.PerformSomeActionOrOther");
     this.Log.WriteLn(String.Format("Exception: {0}", otherUnknownException.Message));
     throw( otherUnknownException );
  }
}
于 2009-01-05T18:16:18.323 に答える
2

「ここで例外処理ブロックを開始する」以外に何が役立つのでしょうか? catch ステートメントに対するコメントの方が優れていますが、一般的には、何を言うつもりですか? 「NullPointerException を処理する」?

アプリケーションドメインの例外への連鎖など、何かエキサイティングなことをしていると言う必要がある場合は、コメントを求めます。

于 2009-01-05T18:19:16.540 に答える
1

よく書かれた try/catch は簡潔で具体的であるべきだと思います。理由がより重要であるという@Jasonに同意しますが、同様に、キャッチ内のコードをできるだけ簡潔に保つことが重要です。

特定の例外を使用してキャッチすることも役立ちます。たとえば、Java を使用している場合は、一般的な例外ではなく、NullPointerException をキャッチしてみてください。これにより、try catch が存在する理由と、それを解決するために何を行っているかが説明されます。

于 2009-01-05T18:16:10.930 に答える
1

あなたが一貫している限り、場所は問題ではありません。私の個人的な好みは次のとおりです。

//comment 1: code does XYZ, can cause exceptions A, B, C
try {
    //do something
}
//comment 2: exception A occurs when foo != bar
catch (ExceptionA a) {
    //do something
}
//comment 3: exception B occurs when bar is null
catch (ExceptionB b) {
    //do something
}
//comment 4: exception B occurs when foo is null
catch (ExceptionC c) {
    //do something
}
于 2009-01-05T18:17:48.727 に答える
0

これがあなたが探している答えではないことはわかっていますが、コメントしないでください。あなたのコードがコメントなしで独立できるほど明確でない場合は、そうなるまでリファクタリングする必要があります。Jeffrey Palerm o は、それを最もよく表しているブログ投稿を書きました。

通常、コメントは次のいずれかを文書化する傾向があります。

  • コンパクトすぎるコード。次のようになります。++i?--g:h-i;
  • 要約する必要がある長いコード ブロック
  • 使い捨てであるか、存在する明確な理由がないコード

例外ブロックに対する簡単なコメントの簡単な例と、コメントの必要をなくしたバージョンについては、以下を参照してください。

bool retries = 0;
while (retries < MAX_RETRIES)
{
    try
    {
        ... database access code
        break;
    }
    // If under max retries, log and increment, otherwise rethrow
    catch (SqlException e)
    {
        logger.LogWarning(e);
        if (++retries >= MAX_RETRIES)
        {
            throw new MaxRetriesException(MAX_RETRIES, e);
        }
    }
    // Can't retry.  Log error and rethrow.
    catch (ApplicationException e)
    {
        logger.LogError(e);
        throw;
    }
}

上記のコメントは再利用性を促進しますが、本質的にコードとコメントの両方を維持する必要があります。コメントなしでより明確になるように、これをリファクタリングすることは可能です (そして望ましいことです)。

bool retries = 0;
while (canRetry(retries))
{
    try
    {
        ... database access code
        break;
    }
    catch (SqlException e)
    {
        logger.LogWarning(e);
        retries = incrementRetriesOrThrowIfMaxReached(retries, e);
    }
    catch (ApplicationException e)
    {
        logger.LogError(e);
        throw;
    }
}

...

private void incrementRetriesOrThrowIfMaxReached(int retries, Exception e)
{
    if (++retries >= MAX_RETRIES)
        throw new MaxRetriesException(MAX_RETRIES, e);

    return retries;
}

private bool canRetry(int retries)
{
    return retries < MAX_RETRIES;
}

後者の例は、非常に微妙な利点のためにコードを追加しているように見えるかもしれませんが、その利点を誇張することはできません。コードも同様に理解できますが、コードを説明するために別のメタデータ (コメント) のセットを用意する必要がないという利点があります。コードはそれ自体を説明しています。catch コード ブロックが長すぎて、要約するためにコメントが必要な場合は、読みやすくするために別のメソッドにリファクタリングすることを検討してください。

于 2009-01-19T18:36:11.503 に答える