私は Flex/Flash Builder を数年間使用してきましたが、今日初めて何かを発見しました。正常に動作する複雑なコードを見ていましたが、その動作を知る必要があったため、コードにブレークポイントを配置して低くすると、例外がスローされました。もう一度取り出したところ、問題なく実行されました（トレースステートメントを使用しても）。これはおかしいと思いました。
簡単に言うと、多くの頭を悩ませた後、コードにゲッターがあり、デバッグプロセス中に変数ビュー (または式ビュー) にゲッターが取得した変数が表示され、Flash Builder デバッガーは、変数ビューに表示される値を計算するためにゲッターを (サイレントに) 実行します。
つまり、特定の状況下では、コードをデバッグすることによって、デバッグしていない場合の実行方法とはまったく異なるパスを実行する場合があります (どのパスをたどるかは、変数ビューを開いていて、その中の var の値)。
これはかなり深刻な欠陥ですか？
私は常に、アプリケーションをデバッグ モードで実行する場合、入力が同一であれば、デバッグしていないときとまったく同じコード パスを実行する必要があると考えていました (ただし、イベント周辺でデバッグする場合、リアルタイムの使用を再現するのはかなり難しくなる可能性があります)。フォーカスを失う/得るためのハンドラーなど)。
もう 1 つの恐ろしい点は、ゲッターがデバッガーによってサイレントに呼び出されることです。つまり、ゲッターにブレークポイントがある場合、デバッガーがそれを呼び出して変数ビューの var の値を更新しても、そこで停止しません。そのため、ゲッターを実行していることにさえ気づきません。
変数ビューの var は、その getter が最終的にコード実行の通常の過程で実行されるまでnullの値を表示するべきではありませんか?
編集 (28/7/11): 私の元の投稿では、セッターが実行されたと述べていましたが、これは間違っています。上記のように、それはゲッターです。そのため、この「欠陥」は、ゲッターのコードが単に var 値を取得する以上の追加機能を実行する場合にのみ存在します-ゲッターのこのような追加機能は、私にとって「コードの匂い」です。したがって、元の欠陥は存在しますが、実際には汚染されたコードのみ