W programie Visual Studio było kiedyś określone pole wyboru „Przerwij w przypadku nieobsługiwanego wyjątku”. W 2015 roku został on usunięty (lub przeniesiony w miejsce, w którym nie mogę go znaleźć). Więc teraz moje przekonwertowane projekty nie psują się, jeśli nie uda mi się zapewnić obsługi wyjątków na poziomie użytkownika. Nie chcę przerywać wszystkich „wyrzuconych wyjątków”, ponieważ obsługuję określone. Właśnie tam, gdzie nie mogę podać konkretnego programu obsługi.
W tej chwili mój kod po prostu wychodzi z bieżącej procedury i kontynuuje wykonywanie w następnej lokalizacji stosu wywołań, NIE DOBRY.
Czy ktoś wie, jak odzyskać to w programie Visual Studio 2015? Właśnie wczoraj uaktualniłem do wersji społecznościowej.
Tool
lub nieWindow
będzie zawierała wszystkich żądanych lokalizacji. W twoim przypadku szukasz ustawień wyjątków .Odpowiedzi:
Pojawiło się nowe okno o nazwie „Ustawienia wyjątków”, które pojawia się domyślnie w prawym dolnym okienku po rozpoczęciu debugowania. Ma wszystkie opcje, których można się spodziewać.
Możesz to wywołać za pomocą CTRL+ ALT+E
Pozwala to na najlepszy wybór wyjątków powodujących przerwę w debugerze.
Kluczowe jest jednak to, że możesz również ustawić, czy te wyjątki zawsze się psują, czy tylko wtedy, gdy jest to nieobsługiwany wyjątek - ale ustawienie tego nie jest zbyt intuicyjne.
Najpierw musisz zaznaczyć „Włącz tylko mój kod” w menu Narzędzia> Opcje> Debugowanie.
Dzięki temu można kliknąć prawym przyciskiem myszy nagłówek kolumny (Przerwij po zgłoszeniu) w nowym oknie Ustawienia wyjątków i dodać kolumnę „Dodatkowe działania”, która następnie umożliwia ustawienie każdego wyjątku jako „Kontynuuj, gdy nie jest obsługiwany w kodzie użytkownika”.
Po prostu kliknij prawym przyciskiem myszy wyjątek lub całą grupę i wyłącz flagę „Kontynuuj, gdy nie jest obsługiwana w kodzie użytkownika”. Niestety, kolumna „Dodatkowe akcje” będzie pusta, co jest tym samym, co „Przerwij po nieobsługiwaniu w kodzie użytkownika”.
Więcej na ten temat tutaj:
http://blogs.msdn.com/b/visualstudioalm/archive/2015/02/23/the-new-exception-settings-window-in-visual-studio-2015.aspx
źródło
Miałem ten sam problem i udało mi się go rozwiązać, robiąc to -
Otóż to!
Zainspirował mnie ten post, ponieważ używam wersji x64 systemu Windows .
źródło
System.ArgumentException
jest obsługiwany, i chwile, kiedy nie. I tylko o łamanie kiedy to nie obchodzić.Dla pracowników Google, którzy chcą się zepsuć tylko wtedy, gdy wyjątek dotyczy ich kodu, w programie Visual Studio 2015 dostępna jest opcja: Opcje-> Debugowanie-> Ogólne-> Tylko mój kod. Po zaznaczeniu pozwala nie przerywać, gdy wyjątek jest zarządzany (zgłaszany i przechwytywany) poza kodem.
źródło
Microsoft subtelnie zmienił logikę w nowym oknie wyjątków.
Zobacz http://blogs.msdn.com/b/visualstudioalm/archive/2015/02/23/the-new-exception-settings-window-in-visual-studio-2015.aspx
Kluczowa część to:
Jeśli jednak tak jak ja masz w swoim kodzie Global Unhandled Exception Handler, to druga pozycja na tej liście jest kluczowa: dla mnie żadne wyjątki nie będą więc naprawdę nieobsługiwane, co wydaje się różnić od VS2013.
Aby powrócić do zachowania, w którym VS przerywa nieobsłużone wyjątki, musiałem zaznaczyć wszystkie typy wyjątków, dla których chciałem przerwać, a następnie upewnić się, że „Dodatkowe opcje” (może być konieczne, aby ta kolumna była widoczna *) dla „Kontynuuj gdy nieobsługiwane w kodzie użytkownika ” NIE zostało ustawione. Wydaje się, że logika VS2015 nie uważa, że mój program obsługi globalnych nieobsługiwanych wyjątków jest „obsługiwany w kodzie użytkownika”, więc nie działa na nich; nie psuje się jednak na złapanych wyjątkach. To sprawia, że działa tak, jak zrobił to VS2013.
* Jak włączyć kolumnę „Dodatkowe działania”
źródło
Jeśli poprawnie czytam między wierszami w tym miejscu, problem polega na tym, że Twój wyjątek skutecznie `` znika '', mimo że domyślne zachowanie debugera powinno zostać przerwane w przypadku nieobsłużonych wyjątków.
Jeśli masz metody asynchroniczne, możesz napotkać ten problem, ponieważ wyjątki, które nie zostały przechwycone w wątku puli wątków jako część kontynuacji zadania, nie są uznawane za nieobsłużone wyjątki. Są raczej połykane i przechowywane wraz z Zadaniem.
Na przykład spójrz na ten kod:
Jeśli uruchomisz ten program z domyślnymi ustawieniami debugera (zatrzymaj tylko w przypadku nieobsługiwanych wyjątków), debuger nie ulegnie awarii. Dzieje się tak, ponieważ wątek puli wątków przydzielony do kontynuacji połyka wyjątek (przekazując go do wystąpienia zadania) i zwalnia się z powrotem do puli.
Zauważ, że w tym przypadku prawdziwym problemem jest to, że
Task
zwracany przezTest()
nigdy nie jest sprawdzany. Jeśli masz podobny typ logiki „wystrzel i zapomnij” w swoim kodzie, nie zobaczysz wyjątków w momencie ich wyrzucenia (nawet jeśli są one „nieobsługiwane” w metodzie); wyjątek pojawia się tylko wtedy, gdy obserwujesz zadanie, czekając na nie, sprawdzając jego wynik lub jawnie patrząc na jego wyjątek.To tylko przypuszczenie, ale myślę, że prawdopodobnie obserwujesz coś takiego.
źródło
Debugger.Break()
wywołanie. Alternatywnie, można dodać wyraźneDebugger.Break()
wTaskScheduler.UnobservedTaskException
obsługi, ale minusem jest to, że może to ogień znacznie później niż w oryginalnym wyjątku, jak to się dzieje na gwincie finalizatora kiedy zadanie zostanie oczyszczone. Ogólnie powinieneś starać się zawsze obserwować wyniki zadań lub przynajmniej mieć blok try-catch do rejestrowania w momencie niepowodzenia.Z mojego doświadczenia wynika, że ustawienia wyjątków w 2015 roku są całkowicie odrzucane, jeśli coś zmienisz.
Spodziewaj się, że jeśli dojdziesz do grupy nadrzędnej "CLR", nie powinieneś otrzymać żadnego przerywającego execpt dla unhandled. Zawsze będziesz przerywać, jeśli wyjątek nie zostanie obsłużony. Ale jeśli masz odznaczoną grupę CLR, kod wewnątrz try ... catch po prostu nie powinien powodować przerwy. Tak nie jest.
Rozwiązanie: W nowym przyborniku ustawień wyjątków kliknij prawym przyciskiem myszy i wybierz „Przywróć domyślne”. Taadaaaa ... Znowu zachowuje się normalnie. Teraz nie rób tego.
źródło
Spróbuj postępować zgodnie z instrukcjami:
https://msdn.microsoft.com/en-us/library/x85tt0dd.aspx
źródło
try { task.Wait(); } catch { ... }
) i wyjątek OperationCanceledException w zadaniu został uznany za nieobsługiwany w kodzie użytkownika.To wszystko jest trochę zagmatwane i moim zdaniem nie tak dobre, jak stare okno dialogowe wyjątków, ale w każdym razie.
Jeśli wyjątek znajduje się na liście i jest zaznaczony, debuger zostanie przerwany za każdym razem, gdy zostanie zgłoszony wyjątek.
Jeśli wyjątek nie jest zaznaczony lub nie ma go na liście, debuger przerwie tylko wtedy, gdy ten typ wyjątku jest nieobsługiwany przez użytkownika.
Na przykład na poniższym zrzucie ekranu debugger zepsuje się za każdym razem, gdy
System.AccessViolationException
zostanie wyrzucony a, ale w przypadku wszystkich innych wyjątków będzie działać tylko wtedy, gdy wyjątek nie został obsłużony przez użytkownika.źródło
Po uaktualnieniu do VS2015 miałem również problemy polegające na tym, że wyjątki kiedyś „łamały” aplikację, ale teraz są ignorowane i od razu pomijane. Są chwile, kiedy chcemy, aby nasz kod celowo generował wyjątki w miejscach, w których chcemy, aby kod zatrzymywał się zamiast kontynuować. Zawsze używamy tego wyrażenia,
Throw New Exception("Message")
aby nasz kod celowo łamał:W VS2015, kiedy mówimy, wyrzucany jest klasyczny „System.Exception”
Throw New Exception
. Dlatego musieliśmy zaznaczyć opcję „System.Exception” w nowych ustawieniach wyjątków:Sprawdź System.Exception Box
Po sprawdzeniu nasz kod działał zgodnie z oczekiwaniami.
źródło
Rozwiązanie jest takie, że semantycznie jest to przeciwieństwo tego, co myślisz, że ustawiasz. Musisz upewnić się, że Kontynuuj, gdy nieobsługiwane w kodzie użytkownika nie jest włączone, tj. Nie jest zaznaczone, jak pokazano w kolumnie Dodatkowe działania w zakładce Ustawienia wyjątków - patrz poniżej:
efektywnie mówisz nie kontynuuj (tj. przerywaj), gdy nie jest obsługiwany w kodzie
Aby to zrobić:
Zrobiło to dla mnie - znowu szczęśliwy.
To było w VS 2015
źródło
Zdecydowanie jest jakiś błąd w programie Visual Studio, który może spowodować zablokowanie go wymagającego ponownego uruchomienia. Nawet VS2015.
Miałem sytuację z pojedynczym wątkiem, w której
NullReferenceException
został złapany przez „zewnętrzny” program obsługi (nadal w moim kodzie), mimo że poprosiłem o jego zerwanie, gdy został podniesiony.Zdaję sobie sprawę, że jest to wyjątek „obsłużony” i mówisz o „nieobsłużonym” - jednak jestem prawie pewien, że czasami szybkie ponowne uruchomienie VS to naprawi, jeśli IISRESET tego nie zrobi.
źródło
Program Visual Studio 2017 działa dobrze z obsługą błędów. Z drugiej strony program Visual Studio 2015 jest do bani w obsłudze błędów w zadaniach, ponieważ w trybie debugowania wszystkie wyjątki występujące w zadaniu asynchronicznym są przechwytywane, ale jeśli przekroczę je, po prostu zawiesza się na czas nieokreślony. Jeśli zostanie wykonany bez debugowania, zawiesza się na czas nieokreślony bez złapania żadnego wyjątku !!! Uwielbiam Visual Studio i używam go od 1995 i 2015 jest zdecydowanie gorszą wersją, chociaż przeskoczyłem bezpośrednio z 2010 do 2015. Spędziłem 8 godzin próbując uzyskać obsługę wyjątku, pracując bez powodzenia. Skopiowałem dokładny kod do 2017 roku na moim domowym komputerze i działał idealnie. Jestem bardzo zirytowany, że Microsoft wepchnął zadania do frameworka, którego kompilator 2015 nie może poprawnie obsłużyć.
źródło