Przeczytałem wiele artykułów (i kilka innych podobnych pytań, które zostały opublikowane w StackOverflow) o tym, jak i kiedy używać asercji i dobrze je zrozumiałem. Ale nadal nie rozumiem, jakiego rodzaju motywacja powinna mnie skłonić do korzystania, Debug.Assert
zamiast rzucać zwykły wyjątek. Chodzi mi o to, że w .NET domyślną odpowiedzią na niepowodzenie asercji jest „zatrzymanie świata” i wyświetlenie okna komunikatu użytkownikowi. Chociaż tego rodzaju zachowanie można zmodyfikować, uważam to za bardzo irytujące i zbędne, podczas gdy zamiast tego mógłbym po prostu zgłosić odpowiedni wyjątek. W ten sposób mógłbym łatwo zapisać błąd w dzienniku aplikacji tuż przed rzuceniem wyjątku, a poza tym moja aplikacja niekoniecznie się zawiesza.
Dlaczego więc, jeśli w ogóle, miałbym używać Debug.Assert
zamiast zwykłego wyjątku? Umieszczenie asercji tam, gdzie nie powinno, mogłoby po prostu spowodować wszelkiego rodzaju „niepożądane zachowanie”, więc z mojego punktu widzenia tak naprawdę nic nie zyskuję, używając asercji zamiast rzucać wyjątek. Zgadzasz się ze mną, czy coś mi tu brakuje?
Uwaga: w pełni rozumiem, jaka jest różnica „w teorii” (debugowanie a wydanie, wzorce użycia itp.), Ale jak widzę, lepiej byłoby rzucić wyjątek zamiast wykonywać asercję. Ponieważ w przypadku wykrycia błędu w wydaniu produkcyjnym nadal chciałbym, aby „asercja” zawiodła (w końcu „narzut” jest absurdalnie mały), więc lepiej będzie, jeśli zamiast tego rzucę wyjątek.
Edycja: Tak jak ja to widzę, jeśli asercja się nie powiodła, oznacza to, że aplikacja weszła w jakiś zepsuty, nieoczekiwany stan. Więc dlaczego miałbym chcieć kontynuować wykonanie? Nie ma znaczenia, czy aplikacja działa w wersji do debugowania czy wydania. To samo dotyczy obu