0

次のような構造のコードがあります。

if (someStatement)
{
    //...
    if (SomeOtherStatement)
    {
        //..., possibly more cases like this
    }
    else
    {
        //goto warning;
        //would otherwise repeat
        //the MessageBox.Show here
    }
}
else
{
    //goto warning;
}
//...
warning:
MessageBox.Show("some warning");

コードのコピーを嫌うので、これはgotoの数少ない便利なアプリケーションの1つですか、それとも使用できるより良い構造がありますか？

4

9 に答える 9

5

これはどうですか？

if (someStatement)
{
    //...
    if (SomeOtherStatement)
    {
        //..., possibly more cases like this

        return; // in the inner-most case
    }
}

MessageBox.Show("some warning");
于 2009-12-03T10:00:39.380 に答える
2

はい。ただし、goto「関数を作成して複数回呼び出す」という意味の場合に限ります。

于 2009-12-03T10:00:53.253 に答える
1

最善のアプローチは、コードの残りの部分がどのように見えるかによって異なります。表示されているコードがそのメソッドの最後のコードである場合：

if(someStatement) {
    // ...
    if(SomeOtherStatement)
    {
        // a couple of lines of code
        return; // !
    }
}

MessageBox.Show("someWarning");

そうでない場合は、おそらく次のようなものにレトルトする必要があります。

if(someStatement) {
    // ...
    if(SomeOtherStatement)
    {
        // a couple of lines of code
    }
    else 
    {
        showWarning("not someOtherStatement");
    }
}
else
{
    showWarning("not someStatement");
}
于 2009-12-03T10:03:38.630 に答える
0

私は個人的に、集中型エラー処理をgotoが受け入れられる「ほぼ唯一のケース」と考えています。ただし、より良い構造にするために、関数の最後に、ラベルを他のラベルの完全に外側に配置します。

于 2009-12-03T09:59:23.283 に答える
0

両方の行に同じエラーメッセージを表示していますか？次に、その行だけを呼び出す関数を作成し、両方の場合にその関数を呼び出す必要があります。

if (someStatement)
{
    //...
    if (SomeOtherStatement)
    {
        //..., possibly more cases like this
    }
    else
    {
        showError();
    }
}
else
{
    showError();
}

ところで：これは悪い例です。エラーをキャッチする単一のelse-branchで解決できます。これがより良いものです：

if (!doSomething())
{
    showError();
}
doSomethingElse();
if (!anotherCall())
{
    showError();
}
于 2009-12-03T10:00:50.897 に答える
0

例外は、.NETでエラーを処理してスローする適切な方法ですが、賢明に使用してください。

try
{
    if (someStatement)
    {
        //...
        if (SomeOtherStatement)
        {
            //..., possibly more cases like this
        }
        else
        {
            throw new MyException();
            //would otherwise repeat
            //the MessageBox.Show here
        }
    }
}
catch(MyException e)
{
    MessageBox.Show(e.Message);
    // log the exception, if necessary
}
finally
{
    // tidy up
}

例外として、何がうまくいかなかったのかについて強く型付けされた答えが得られ、それをロギングシステムに簡単に実装できます。

于 2009-12-03T10:05:03.900 に答える
0

あなたが持っているような深刻な厄介なエラーテストステートメントに入るつもりなら、それを単一のtry / catchでラップし、ifステートメント内から適切なアプリケーション固有の例外をスローしてそれらの特定の例外をキャッチすることを検討することをお勧めしますキャッチブロックで、他のすべての人をチェーンのさらに上流でキャッチさせます。

于 2009-12-03T10:06:27.843 に答える
0

（FrameWork 1.1以降）論理積-および "&&"："必要な場合にのみ2番目のオペランドを評価します。"

どうしたの ：

if(someStatement && someOtherStatement)
{
       // more whatever
}
else
{
       // raise an exception, call a method, show messagebox, whatever
}

最初の句がtrueと評価された場合に行われる論理評価の複雑さに応じて：そして、おそらく、他の多くのテストを実装しますが、その数に関係なく、エラーが発生する可能性があります：すべて同じ方法で処理する必要があります：I ' d特定の例外を発生させるか、エラーを処理するメソッドを呼び出すか、すべてをtry-catchブロックに入れることが必須であると考えます（コードが多い場合は非常に醜い可能性があります）。

エラーの可能性がコードが呼び出された時間の99％で非常に遠いという合理的な推定である場合に使用する、ローダウンダーティ卑劣な方法：エラー状態を反映するためにブールフラグを設定します：評価複雑なコードブロックの完了時にそれを実行し、必要なことを実行します。もちろん、これらの内部評価の結果としてコードがどこかで分岐した場合、それは良いことではありません。

于 2009-12-03T10:25:45.077 に答える
0

後藤は悪い考えだと思います。ジャンプする必要がある場合は、joshcomleyによって提案されているように、例外をスローします。警告メッセージを出力したいが、ジャンプせずに続行したい場合は、メソッドを呼び出します。

于 2009-12-03T10:30:32.140 に答える