7

私はちょうどプロジェクトで見つけました：

try
{
    myLabel.Text = school.SchoolName;
}
catch
{
    myPanel.Visible = false;
}

schoolnull 例外が発生すると (理論的には null ではない可能性があるためmyLabel)、実質的にコンピューターが3 回ビープ音を鳴らし、2 秒間スリープ状態になると言って、これを書いたよりも開発者と話したいです。しかし、それについてのルールは記憶違いなのだろうか。明らかに、これは try/catch の使用を意図したものではありませんが、これは意図に反するため悪いのでしょうか、それともパフォーマンスを考慮して悪いのでしょうか? ただ悪いだけのような気もするが、「本当に悪い」以上のことを言いたい。

4

9 に答える 9

21

設計が悪いという理由だけで、制御フローに例外を使用しないでください。それは意味がありません。例外は例外的な場合であり、通常のフローではありません。最新のハードウェア上のほとんどの最新のアプリケーションでは、1日中例外をスローでき、ユーザーはパフォーマンスの低下に気付かないため、この状況ではパフォーマンスはおそらく問題になりません。ただし、これが大量のデータを処理したり、ある種の作業を実行したりする高性能アプリケーションである場合は、そうです、パフォーマンスが問題になります。

于 2009-08-26T16:53:15.487 に答える
9

私の意見では、これは if ステートメントでより明確にできるため、不十分です。

if (school != null) {
    myLabel.Text = school.SchoolName;
}
else {
    myPanel.Visible = false;
}

これにより、例外処理を不必要に使用することが確実に回避され、コードの意味が非常に明確になります。

于 2009-08-26T17:02:50.647 に答える
8

これは、1つの例外に対してコーディングしており、不要なオーバーヘッドも継承するため、悪いことだと思います。例外は、特定の方法で処理される場合にのみキャッチする必要があります。

例外は、予測できない例外の場合に特にキャッチする必要があります。この場合、学校がnullになる可能性があるかどうかを確認する簡単なチェックです。実際、学校がnullになる可能性があります（ラベルが何も設定されていないため）。学校がnullであり、それがそれ自体のArgumentNullExceptionをスローするよりもそうであるべきではなかった場合。

于 2009-08-26T16:50:33.667 に答える
3

例外によって実行時のオーバーヘッドが発生しますが、ここではおそらく無視できる程度です。デバッガーでの実行には違いがありますが、ビルドされたバイナリはほぼ同じ速度で実行されるはずです。

チンパンジーなら誰でもマシンが読めるコードを作成できることを開発者に伝えてください。良いコードは、機械ではなく人間のために書かれています。心配していることが null 例外だけである場合、それはおそらくユーザーのコードのバグです。誰もそのように null を割り当てようとするべきではありません。Assert()代わりにステートメントを使用してください。

于 2009-08-26T16:54:31.273 に答える
2

これは悪いことだとあなたは絶対に正しい。意図に反し、パフォーマンスを損なうため、悪いです。

さまざまなプログラミング スタイルの余地があることは認識していますが、個人的には、これが機能し、コードが何をしようとしているのかを確認できたとしても、可読性とコードの明瞭性が損なわれ、メンテナンスがはるかに難しくなっていると思います。フォローするプログラマー。ここでは、if ステートメントの方が適切です。

于 2009-08-26T16:53:40.900 に答える
2

例外のスローは、パフォーマンスに悪影響を及ぼします。http://msdn.microsoft.com/en-us/library/ms229009( VS.80 ).aspx を参照してください。

于 2009-08-26T16:53:47.700 に答える
1

フロー制御に例外を使用するのは好きではありません。例外はコストがかかり、コード内の他の場所に到達するためにスローされる例外を除いて、プログラムの実際のフローを判別することは困難です。私にとって、これはGoToを使用するようなものです。これは、例外を回避する必要があるという意味ではなく、プログラムで通常発生するはずの例外であるという意味です。

コードの悪い部分は、例外を除いて何もしていないことだと思います。例外がスローされる理由についてのログや説明さえありません。

于 2009-08-26T16:52:53.693 に答える
1

「通常の制御フローとして例外を使用しないのはなぜですか?」に関するこの投稿を確認してください。

于 2009-08-26T17:03:54.967 に答える
1

私はここにいる全員に同意します。それは恐ろしい考えです。

Java には、特定の「非例外」ケースの例外をキャッチする必要がある場合がいくつかあります (現在はほとんどなくなっていると思いますが、外部ライブラリにはまだいくつかある可能性があります)。

一般に、ライブラリ コード (実際にはどのクラスでも) を作成するときは、回避できる可能性のあるものすべてに例外を使用しないでください。name フィールドが設定されておらず、write() メソッドで例外が発生する可能性がある場合は、isValid() メソッドを追加して、実際に書き込みの周りで例外をキャッチして知る必要がないようにしてください。問題がある。

(悪い Java コードの補遺): この「良い」プログラミング スタイルは、Java でのチェック済み例外の必要性を事実上なくし、Java でのチェック済み例外はサックです。

于 2009-08-26T17:14:21.047 に答える