以前の質問への回答のおかげで、これについてある程度の進歩がありました。これは、すでにここで説明したものの重複した症状であることが判明しました。TLDR バージョン: Win64 でのデバッグは、Form_Load イベントで「奇妙な」動作をします。
私が今やろうとしているのは、これに対処する最善の方法を見つけ、VS を適切に動作させて、実際にプログラミング/デバッグに取り掛かることができるようにすることです。さまざまな場所に非常に多くの設定があるため、すべてを追跡するのは困難です。これらのすべての組み合わせで完全なテストを行いました:
a. ビルド プラットフォーム: 任意の CPU または x64
b. 「32 ビットを優先」 (x64 を選択した場合は該当なし)
c. マイ コードのみ (有効/無効)
d. スローされたすべての例外で中断します (ユーザーが処理しないものだけではありません)。
e. Form.Load または Form.New で例外をスローする
一定に保つ: Application Framework が有効。スタートアップ オブジェクトは Form1 であるため、次の非ユーザー コードから呼び出されます。
Protected Overrides Sub OnCreateMainForm()
Me.MainForm = Global.TheNameOfMyApplication.Form1
End Sub
長いため、ここに完全な結果を投稿することはできません。また、これらの投稿で表を作成する方法が見つかりません。しかし、結論として、VS デバッガーには 4 つの異なる動作が見られます。良いものから悪いもの、非常に醜いものの順に並べると、次のようになります。
1.例外の原因となった実際の行でブレークします。これは「適切な」動作です。
2. OnCreateMainForm (上記) の行で改行します。内部例外は、汚れを与えます。例外がスローされたプロシージャ内でブレークする方法はありません(たとえば、実際に何が起こっているかを見てください)。
3.空白 (コードなし) ウィンドウで中断します。上部に「利用可能なソースがありません: コール スタックには外部コードのみが含まれています」と表示されます。
4.休憩なし。例外が飲み込まれました。例外がスローされる手順は破棄されます。スロー後の行は実行されません。私が気付かないことを願って、幸せな口笛を吹いて、プログラムは続きます。
明らかに私は振る舞いが欲しい1。これが私が見つけたものです。
- Build Platform と "Prefer 32-bit" の設定は、このテストではまったく違いがありません。
- ([デバッグ/例外] ダイアログで) スローされた例外でブレークを有効にすると、すべてが適切に機能します (良い動作1 )。
- これを有効にしないと、Form.Load のコードは常に醜い動作4 (飲み込まれた例外) になります。
- これを有効にしないと、Form.New のコードは 2 つのことのいずれかを行います。JustMyCode が有効になっている場合、悪い動作3 (「利用可能なソースがありません」) が発生します。そうでない場合は、悪い動作2が発生します (フォームを作成する呼び出しを中断します。何が起こっているのかを確認するために New コンストラクターに入ることができません)。
Form.Load ではなく Form.New でのコーディング (以前の質問への回答でアドバイスされているように) が回避策になることを望んでいました。そうではないことがわかりました。何か不足していない限り、デバッグを機能させる唯一の方法は、スローされた例外でブレークを有効にすることです。これを行う必要はありません。とりわけ、私は例外をキャッチして選択的に処理したいと考えており、スローされたすべての例外を中断することで、これを処理するための完全な PITA になります。
(このプロジェクトは、この問題に遭遇する前に、Hello World ステージを少し通過しただけであることに注意してください。私はまだファンクなことをしていません。実際に、PITA デバッガーの動作が私の首にぶら下がっていることは望んでいません。 )。
事実上、私が本当に探しているオプションの代わりとして、すべての「スローされた例外でブレーク」ボックスにチェックを入れる必要があります。
以前の回答に記載されている修正プログラムもインストールし、Sub Main プロシージャで例外ハンドラーを設定しようとしましたが、それでも問題は解決しないようです。この Break on Thrown Exceptions は私の最良の選択肢ですか?