7

LoadWinFormsまたはLoadedWPFのイベントハンドラー内に次のコードを配置してみてください。

Dim doc As New XmlDocument
Dim nsmgr As New XmlNamespaceManager(Nothing) 'this line throws an exception

問題は、例外がスローされず、スタックの破損が発生することです。IDEによっては、さまざまな副作用が発生する可能性があります。以下を参照してください。

  • 影響を受けるIDEは、2008年、2010年、および2012年です(テストできたもの)。2010はスタック状態をリセットし、何も起こらなかったように(ただし、他のステートメントを続行せずに)サブ/ハンドラーから戻ります。2012は、失敗したアプリケーションとでの実行の試みについてユーザーに警告する場合がありますcompatibility mode。その後、2010年と同じように実行されます。2008は例外を適切にスローしますが、デフォルト構成(AnyCPU)でのみ実行されます。プラットフォームターゲットをx86に切り替えると、2008年にも問題が再発します。
  • 影響を受けるフレームワークは、WinFormsとWPFです。コンソールアプリとASP.NETは正常に機能しているようです。.NETv2.0-4.5。
  • 影響を受けるスコープはLoad、これまでのところイベントのみです。このコードをボタンに入れると機能します。
  • 影響を受けるビルド構成=任意。デフォルトDebugで試してみましたRelease

私がそれをバグと見なす理由は、オブジェクトが不安定な状態のままになる可能性があるためです。オブジェクトは初期化を完了しませんでした。これは予期された動作ではありません。それについて重要なのは、例外をスローしないため、誰もそれが起こったことを知らないということです。設計によっては、データベースに誤ったデータが含まれる可能性があり、最悪の場合、深刻な結果につながる可能性があります。

なぜこれが起こっているのか、そして回避策があるかどうかについて誰かが良い説明をしていますか?

4

1 に答える 1

2

この問題は、x64OSでx86プラットフォームをターゲットにしたときに機能するwow64エミュレーションレイヤーが原因で発生します。
Loadイベントの発生を担当するコード内の例外を飲み込みます。
したがって、デバッガーは例外を認識せず、状況を処理するために介入することはできません。この記事はそこで何が起こっているのか
をよく文書化しているようです、

Hans Passantからのこの以前の回答(すべてのクレジットと賛成票があります)は、考えられる回避策を説明しています。
私の好みの1つは、Form_Loadイベントからすべてを移動し、問題のあるコードをフォームコンストラクターに配置することです。(もちろん、あなたの場合に当てはまるかどうかはわかりません)

于 2012-10-31T22:33:13.517 に答える