Каковы преимущества использования системы.Диагностика.Отладчик.Break () над присоединением к процессу?

используя Visual Studio 2008, чтобы начать отладку в зависимости от моего настроения, я либо присоединюсь к процессу и нажму точки останова, либо помещу .Диагностика.Отладчик.Break () в соответствующем месте кода и начать отладку, когда он ломается в этот момент.

последнее необходимо иногда я нахожу!

Не говоря о Ф5 --> запуск в режиме отладки для второй...

System.Diagnostics.Debugger.Break();

вопросы:

Q) мне любопытно узнать о незначительных различиях между каждым вариантом?

Q) каковы преимущества и недостатки использования каждого?

Я начну...

отладчик.Перерыв() недостаток = забыв об отладчике.Break () и оставить их там!

отладчик.Break () benefit = начать отладку именно там, где вы хотите, не задев другие ненужные точки останова, которые может все еще быть в коде, который будет поражен, если он будет подключен к процессу.

превзойти ненавистников

Я просто упредить ненавистников, которые, несомненно, сказать, если я использую отладчик.Break () я не понимаю правильного способа отладки.

Я просто пытаюсь начать разговор здесь, как я считаю, есть разные способы отладки в зависимости от обстоятельств.

6
c# debugging

2 ответов

Я когда-то работал над плагином на основе приложения, которое сделало много вещей при запуске. Это сделало бы открытие плагина среди многих других вещей. Я не мог запустить его непосредственно из Visual Studio, так что Ф5 не было вариантом, но подключить к отладчику также не был вариантом, потому что много раз мне нужно было бы отлаживать все, что происходит при запуске. Я никогда не смогу поймать его вовремя с помощью Attach to process. Поэтому я просто устанавливаю отладчик.Break () именно там, где я хотеть.

другой пример; я писал командлет для PowerShell. Те, которые вы не запускаете в Visual Studio; вы запускаете их из командной строки PowerShell. Они, как правило, быстрые маленькие приложения, и вы не сможете поймать их вовремя с присоединить к процессу.

12

в дополнение к ответу BFree я обнаружил, что перерыв иногда полезен при работе с плохо разработанным устаревшим продуктом. Этот конкретный продукт имел плохую привычку глотать или игнорировать исключения, и его механизмы регистрации не работали (на самом деле, никогда не работали) должным образом. Он часто нарушал многие хорошие практики, которые требовали, чтобы клиенту "повезло", чтобы заставить его работать во время выполнения. Я начал добавлять быструю кляксу кода:

if(System.Diagnostics.Debugger.IsAttached)
{
    System.Diagnostics.Debugger.Break();
}

к определенным местам, которые я был фокусировка на отладке. Это позволило мне легче видеть, что происходит, когда и что нарушается, не нарушая код, когда он был запущен клиентом. (Моя несбыточная мечта состоит в том, что это также, надеюсь, прояснилось в моем несколько менее осведомленном коллеге.)

Да, я знаю, что это не особенно хорошая практика и я бы никогда не сделать это в новом кодексе. Но поверь мне, если бы ты копался в базе кода, ты бы сделал что-то подобное. ;)

6