Jeśli zdarzyło wam się kiedyś debugować przez Console.WriteLine(…) lub dzielić przez zero, tylko po to aby odpalił się debugger I podpinać do tego visual studio to ta linijka będzie dla was na wagę złota:
System.Diagnosticks.Debugger.Launch();
Gdy wykonywany kod dojdzie do tej linijki pojawi się okienko z pytaniem czy chcesz debugować aplikację, po “jesie” VS dopina się do procesu I normalnie można korzystać z dobrodziejstw inwentarza. Sztuczka przydatna gdy kod jest uruchamiany przez zewnętrzny proces, a wy dostarczacie jedynie bibliotekę z kodem.
Debugger.Launch() uwalnia od wszelkiej maści dzielenia przez zero, pisania na konsole, rzucania wyjątków, robienia MessageBox, żeby zaczekało na dopięcie debuggera, sleepów, etc. Złoto!
Namiętnie korzystam jeszcze z tego: Debugger.IsAttached.
Bardzo przydatne!
A kiedy i do czego? Nie mam aktualnie pomysłu kiedy mogłoby mi się takie sprawdzenie przydać.
Dostajesz informację czy jest zapięty dubugger, czy nie. Może się przydać w przeróżnych sytuacjach, np:
* twój system kolejkuje przetwarzanie pewnych danych, to zamiast kolejkować zadanie i czekać na ściągnięcie a potem na wynik, to możesz skorzystać z tej property i przetworzyć od razu
if (Debugger.IsAttached)
return Processor.Process(someData);
else
EnqueueWork(someData)
* twój system pokazuje pełną zawartość formatki tylko w specjalnym statusie
var showFullContent = currentStatus == Statuses.SpecialOne || Debugger.IsAttached
Moje przykłady są wymyślone na poczekaniu niemniej jednak mam nadzieję, że przekazałem ideę 🙂
Jasne. Kupuje pomysł.