Ausnahmen ignorieren, die in einer Bibliothek ausgelöst und abgefangen werden

Question

Die Python-Standardbibliothek und andere Bibliotheken, die ich verwende (z. B. PyQt), verwenden manchmal Ausnahmen für Nicht-Fehler-Bedingungen. Sehen Sie sich Folgendes an, mit Ausnahme der Funktion os.get_exec_path(). Es verwendet mehrere try-Anweisungen, um Ausnahmen abzufangen, die beim Versuch, einige Umgebungsdaten zu finden, ausgelöst werden.

try: 
    path_list = env.get('PATH') 
except TypeError: 
    path_list = None 

if supports_bytes_environ: 
    try: 
     path_listb = env[b'PATH'] 
    except (KeyError, TypeError): 
     pass 
    else: 
     if path_list is not None: 
      raise ValueError(
       "env cannot contain 'PATH' and b'PATH' keys") 
     path_list = path_listb 

    if path_list is not None and isinstance(path_list, bytes): 
     path_list = fsdecode(path_list) 

Diese Ausnahmen bedeuten keinen Fehler und werden unter normalen Bedingungen ausgelöst. Bei Verwendung von Ausnahme-Breakpoints für eine dieser Ausnahmen bricht der Debugger auch diese Bibliotheksfunktionen auf.

Gibt es einen Weg in PyCharm oder in Python im Allgemeinen, den Debugger nicht auf Ausnahmen zu brechen, die innerhalb einer Bibliothek geworfen und gefangen werden, ohne meinen Code einzubeziehen?

Answer 1

Diese Funktion ist noch nicht implementiert ist, können Sie für ihn stimmen:

• add ability to break (add breakpoint) on exceptions only for my files

Answer 2

Es gibt eine andere SO mit einer Lösung zu beantworten ist: Debugging with pycharm, how to step into project, without entering django libraries

Es ist für mich arbeitet , außer dass ich immer noch in die "_pydev_execfile.py" -Datei gehe, aber ich bin nicht in andere Dateien getreten, nachdem ich sie zum Ausschluss in der verknüpften Antwort hinzugefügt habe.

Answer 3

in PyCharm, gehen Sie zu Run -> View Breakpoints, und überprüfen Sie "On raise" und "Ignoriere Bibliotheksdateien".

Die erste Option macht den Debugger stoppen, wenn eine Ausnahme ausgelöst wird, anstatt nur, wenn das Programm beendet wird, und die zweite Option gibt PyCharm die Politik Bibliotheksdateien zu ignorieren, also vor allem in Ihrem Code zu suchen.

Die Lösung wurde dank CrazyCoder 's link zu der Feature-Anfrage gefunden, die seither hinzugefügt wurde.

Answer 4

Eine Zeit lang hatte ich eine komplizierte Regelung, die in etwa wie folgt beteiligt: ​​

try(Closeable ignore = Debugger.newBreakSuppression()) 
{ 
    ... library call which may throw ... 
} <-- exception looks like it is thrown here 

Das erlaubte mir nie von Ausnahmen belästigt werden, die innerhalb Bibliothek Anrufe geworfen und geschluckt wurden. Wenn eine Ausnahme von einem Bibliotheksaufruf ausgelöst wurde und nicht abgefangen wurde, würde es so aussehen, als wäre sie in der schließenden geschweiften Klammer aufgetreten.

Die Art und Weise war es funktionierte wie folgt:

Closeable eine Schnittstelle, die AutoCloseable ohne Deklaration erstreckt, ist jede Ausnahmen geprüft.

ignore ist nur ein Name, der IntelliJ IDEA sagt, sich nicht über die unbenutzte Variable zu beschweren, und es ist notwendig, weil albernes Java try(Debugger.newBreakSuppression()) nicht unterstützt.

Debugger ist meine eigene Klasse mit Debugging-verwandten Hilfsmethoden.

newBreakSuppression() war eine Methode, die eine Thread-lokale Instanz von einigen BreakSuppression Klasse erstellen würde, die die Tatsache zur Kenntnis nehmen, dass wir Break-on-Ausnahme vorübergehend ausgesetzt werden möchten.

Dann hatte ich eine Ausnahme Haltepunkt mit einer Pause Bedingung, dass meine Debugger Klasse aufrufen würde zu fragen, ob es in Ordnung ist, zu brechen, und die Debugger Klasse würde mit einem „Nein“, wenn irgendwelche BreakSuppression Objekte wurden instanziiert reagieren.

Das war extrem kompliziert, weil die VM Ausnahmen auslöst, bevor mein Code geladen wurde, so dass der Filter während des Programmstarts nicht ausgewertet werden konnte und der Debugger ein Popup-Fenster öffnen würde, anstatt es zu ignorieren. (Ich beschwere mich nicht, ich hasse stille Fehler.) Also musste ich einen schrecklichen, schrecklichen, nicht-versuchen-dieses-zu-Hause-Hack haben, wo die Unterbrechungsbedingung so aussehen würde: java.lang.System.err.equals(this) Normalerweise, das würde niemals true zurückgeben, weil System.err ungleich einer ausgelösten Ausnahme ist, deshalb würde der Debugger niemals brechen. Wenn jedoch meine Klasse Debugger initialisiert würde, würde sie System.err durch eine eigene Klasse ersetzen, die eine Implementierung für equals(Object) lieferte und true zurückgab, wenn der Debugger brechen sollte. Im Wesentlichen benutzte ich System.err als eine ewige globale Variable.

Schließlich habe ich dieses ganze Schema aufgegeben, weil es übermäßig kompliziert ist und sehr schlecht läuft, weil Ausnahmen sehr oft im Java-Ökosystem auftreten, also einen Ausdruck jedes Mal auszuwerten, wenn eine Ausnahme ausgelöst wird, verlangsamt alles enorm.