Stoppen Sie den Debugger nicht bei dieser Ausnahme, wenn er ausgelöst und abgefangen wird.

In tools/exceptions habe ich die Option gesetzt, dass der Debugger stoppt, wenn eine Ausnahme ausgelöst wird. Ob es gefangen ist oder nicht.Stoppen Sie den Debugger nicht bei dieser Ausnahme, wenn er ausgelöst und abgefangen wird.

Wie schließe ich eine Ausnahme dieser Regel aus? Irgendwo in meinem Code gibt es eine abgefangene Ausnahme, die Teil der Programmlogik ist. Daher möchte ich natürlich nicht, dass die Ausnahme den Debugger bei jedem Treffer stoppt.

Beispiel: Ich möchte die Nullreferenz-Ausnahme (die gefangen wird) in Zeile 344 ignorieren. Ich möchte bei allen anderen Ausnahmen stoppen

Quelle

2009-09-14 MichaelD

Wenn diese Ausnahme Teil Ihrer Programmierlogik ist (man denke etwa, wenn Sie es wirklich auf diese Weise implementieren müssen) - Dann sollte es mindestens eine eigene, abgeleitete Ausnahme sein. Auf diese Weise können Sie die Lösung von Brian anwenden. – tanascius

Hier ist das Problem: http://stackoverflow.com/questions/1957907/how-do-i-know-when-a-lambda-expression-is-null – MichaelD

@tanascius - +1 Ich stimme in den meisten Fällen Ausnahmen sind nicht der beste Weg, um eine logische Entscheidung zu treffen; In einigen Fällen jedoch, wenn das Deserialisieren von Handlingsausnahmen manchmal unvermeidbar ist, ist die Option throw> catch> handle die einzig sinnvolle Option. – jpierson

Wenn ich mich richtig erinnere, können Sie ein DebuggerStepThrough Attribut für die Methode verwenden, die den Code enthält, den die Ausnahme nicht auslösen soll. Ich nehme an, Sie können den Code, der die lästige Ausnahme in einer Methode auslöst, isolieren und mit dem Attribut dekorieren.

Quelle

2009-09-14 23:40:27

großartig! thx für die Info – MichaelD

+30

Aus der Antwort von malinger und meiner Erfahrung scheint diese Antwort falsch zu sein. Das Attribut "DebuggerStepThrough" hat keine Auswirkungen auf das Verhalten des Debuggers bei Ausnahmen der ersten Chance. –

Ja, Sie haben Recht. Ich habe es gerade ausprobiert. Ich zweite tanascius darauf, dass es ein Design-Problem scheint. Sie können zuerst prüfen, ob etwas null ist, ohne Ausnahmen auszulösen. –

Sie können keine Ausnahme an einer bestimmten Stelle in Ihrem Code auslösen. Sie können jedoch Ausnahmen eines bestimmten Typs deaktivieren.

Wenn Ihr eigener Code die fragliche Exception auslöst, würde ich eine benutzerdefinierte Exception machen, abgeleitet von was auch immer passt, und dann Debug-Breaking für diesen abgeleiteten Typ deaktivieren.

Das Deaktivieren von Systemausnahmen als NullReferenceException wirkt sich auf das gesamte System aus, was natürlich während der Entwicklung nicht erwünscht ist.

Beachten Sie, dass es zwei Arten von Bruch-Verhalten für Ausnahmen:

Geworfen: Wenn diese Option aktiviert, bricht, sobald eine Ausnahme von dieser Art
Benutzer unhandled geworfen wird: Wenn diese Option aktiviert, Pausen Nur wenn die Ausnahme dieses Typs nicht von try/catch gehandhabt wird.

Sie könnten die Kontrolle in ‚Thrown‘ für die Nullreferenceexception entfernen, die Sie in den Genuss von nicht jedes Mal bricht das System die betreffende Zeile im Code passiert, aber brechen immer noch, wenn Sie etwas nicht behandelte Nullreference expection haben geben in anderen Teilen des Systems auftreten.

Quelle

2009-09-14 09:17:24

Das Hinzufügen des DebuggerStepThrough-Attributs zu einer Methode in Visual Studio 2010 verhindert, dass der Debugger angehalten wird und eine nicht behandelte Ausnahme von der Methode ausgelöst wird. –

Ich habe getestet und es verhindert nicht; es stoppt immer noch – Shimmy

@Shimmy - Arbeiten für mich! Stellen Sie sicher, dass Sie DebuggerStepThrough auf jede Methode anwenden, von dem Punkt, an dem sie ausgelöst wird, bis zu dem Punkt, an dem die Ausnahme in der Aufrufliste sichtbar sein soll. Wenn Sie die Ausnahme abfangen und sie in der Aufrufhierarchie behandeln, in der alle Methoden mit DebuggerStepThrough versehen sind, sollten Sie nie sehen, dass VS bei dieser Ausnahme bricht. – jpierson

DebuggerHidden ist dein Freund!

Die Common Language Runtime fügt diesem Attribut keine Semantik hinzu. Es wird zur Verwendung von Quellcode-Debuggern bereitgestellt. Der Visual Studio 2005-Debugger stoppt beispielsweise nicht in einer mit diesem Attribut gekennzeichneten Methode und lässt keinen Haltepunkt in der Methode zu. Andere Debuggerattribute, die vom Visual Studio 2005-Debugger erkannt werden, sind das DebuggerNonUserCodeAttribute und das DebuggerStepThroughAttribute.

Getestet auf VS2010 und funktioniert gut.

Während DebuggerStepThrough scheint auch für einige spezifische Debugger-Versionen zu arbeiten, scheint DebuggerHidden für eine größere Auswahl an Situationen basierend auf den Kommentaren zu beiden Antworten zu arbeiten.

Beachten Sie, dass beide Optionen derzeit nicht mit iterator block methods oder für async/await methods arbeiten. Dies könnte in einem späteren Update von Visual Studio behoben werden.

Quelle

2010-08-11 03:35:35 Shimmy

arbeitet an VS2008. Sie müssen es auf die gesamte Methode einschließlich der catch-Block anwenden, oder Sie werden nur woanders brechen –

Ich habe dieses Attribut zu einer Methode hinzugefügt und der Debugger nur auf dem aufrufenden Methond davon gestoppt. Fehle ich etwas? – Doogal

So sollte es sein. um das zu vermeiden, müssen Sie die Ausnahme behandeln ... Alternativ können Sie auch die Aufrufmethode als DebuggerHidden markieren ... – Shimmy

DebuggerStepThrough ist derjenige, der verwendet wird, um zu verhindern, dass der Debugger eine Methode einbricht, bei der ein try/catch auftritt.

Aber es funktioniert nur, wenn Sie nicht die Option "Nur meinen Code aktivieren (nur verwaltete)" in den allgemeinen Einstellungen der Debugging-Optionen von Visual Studio (Menü Extras/Optionen, Knoten Debugging/Allgemein) deaktivieren ...

Mehr Informationen zu diesem Attribut auf http://abhijitjana.net/2010/09/22/tips-on-debugging-using-debuggerstepthrough-attribute/

DebuggerHidden einfach den Debugger verhindern, dass die Methode anzuzeigen, in dem die Ausnahme ausgelöst wird. Stattdessen wird die erste Methode auf dem Stapel angezeigt, die nicht mit diesem Attribut gekennzeichnet ist.

Quelle

2012-08-10 07:28:39

Beachten Sie, dass dies in VS 2015 nicht mehr standardmäßig funktioniert, [siehe VS-Blog für wie es aktiviert wird] (https: // blogs .msdn.microsoft.com/visualstudioalm/2016/02/12/using-the-debuggernonusercode-attribute-in-visual-studio-2015/#) – sparsely

Die Attribute, die in den anderen Antworten (und anderen wie dem Attribut DebuggerNonUserCode) angegeben sind, funktionieren standardmäßig nicht mehr auf die gleiche Weise in Visual Studio 2015. Der Debugger wird Ausnahmen auf dem Methodenmarkt mit diesen Attributen brechen, im Gegensatz zu älteren Versionen von VS. So deaktivieren Sie die Verbesserung der Leistung, die ihr Verhalten geändert benötigen Sie eine Registrierungseinstellung ändern:

reg add HKCU\Software\Microsoft\VisualStudio\14.0_Config\Debugger\Engine /v AlwaysEnableExceptionCallbacksOutsideMyCode /t REG_DWORD /d 1

Weitere Informationen finden Sie auf den visual studio blog finden.

(Dies ist wahrscheinlich ein Kommentar auf der Top-Antwort sein sollte, aber ich habe nicht genug rep)

Quelle

2016-02-23 14:44:05 sparsely

Stoppen Sie den Debugger nicht bei dieser Ausnahme, wenn er ausgelöst und abgefangen wird.

Antwort

Verwandte Themen