0

私は今日、これを理解しようとして夢中になっています。ファイルの変更をキャプチャするために、しばらく FileSystemWatcher を使用しています。もともとフレームワーク 3.5 にあった私のプロジェクトの 1 つは、いくつかの EF を利用するために 4.0 に移動され、FileSystemWatcher を利用するコードを Visual Studio でデバッグする方法に影響を与えたようです。これが私が抱えている問題の小さな例です（watcher_Changedを参照）：

class Program
{
    static void Main(string[] args)
    {
        FileSystemWatcher watcher = new FileSystemWatcher(@"C:\inputFolder\");

        watcher.Changed += new FileSystemEventHandler(watcher_Changed);
        watcher.NotifyFilter = NotifyFilters.LastAccess
            | NotifyFilters.LastWrite
            | NotifyFilters.FileName
            | NotifyFilters.DirectoryName;

        Console.WriteLine("Ready");

        watcher.EnableRaisingEvents = true;
        Thread.Sleep(System.Threading.Timeout.Infinite);
    }

    static void watcher_Changed(object sender, FileSystemEventArgs e)
    {
        //This exception here (just an example), does not get sent to the debugger, rather it goes to the
        //console and then the application exits
        throw new ArgumentException();
    }
}

ArgumentException をコンソールに投げた後、コードは常に閉じます。これにより、より複雑なシナリオでいくつかの主要なデバッグの問題が発生しています。

何か案は？

4

1 に答える 1

0

System.ArgumentExceptionこれは、Visual Studioがスローされたときではなく、ユーザーが処理したときに壊れるように構成されていないためだと思います。によって作成されたスレッドで例外が発生しているFileSystemWatcherため、おそらくトップレベルの例外ハンドラーはありません。

デバッグ設定を変更するには、Debug\Exceptions に移動し、展開Common Language Runtime Exceptionsして例外を検索します。Find...ボタンを使用することもできます。次に、「スロー」チェックボックスがチェックされていることを確認します。多くのアプリケーションは例外を正常に処理する可能性があるため、このオプションは通常は必要ないことに注意してください。

于 2013-01-07T22:06:01.020 に答える