Каковы преимущества использования System.Diagnostics.Debugger.Break () перед Присоединением к процессу?

Question

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

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

Не говорю о F5 -> работающем в режиме отладки в течение секунды ...

System.Diagnostics.Debugger.Break();

Вопросы:

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

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

Я начну ...

Недостаток Debugger.Break () = забывая о Debugger.Break () и оставляя их там!

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

Предотвращение ненавистников

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

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

Answer 1

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

Другой пример; Я писал командлет для PowerShell. Те, которые вы не запускаете в Visual Studio; вы запускаете их из командной строки PowerShell. Как правило, это небольшие быстрые приложения, и вы не сможете вовремя их поймать с помощью Присоединение к процессу .

Answer 2

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

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

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

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