Error Handling #24
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Ein paar Stellen im code haben kein Richtiges Error Handling. Muss unbedingt gemacht werden! Inkl. Log ins Log System.
Beispielcode:
`
import traceback
try:
# Wieder unser Standard-Fehler
ergebnis = 10 / 0
except Exception as e:
# 1. Den rohen "Diagnosepuffer" aus dem Fehler auslesen
roh_daten = e.traceback
e.traceback: Die Variable e (unser aufgefangener Fehler) hat versteckte Eigenschaften. Alles, was in Python mit zwei Unterstrichen davor und danach geschrieben wird (sogenannte "Dunder"-Methoden/Eigenschaften), sind interne Systemvariablen. Hier liegt der rohe Speicherabzug des Absturzes.
traceback.extract_tb(...): Diese Funktion nimmt die rohen Systemdaten und macht daraus eine übersichtliche Liste mit allen Stationen, die das Programm durchlaufen hat
1
.
Warum aufruf_liste[-1]?
Stell dir vor, dein Hauptprogramm (OB1) ruft ein Unterprogramm auf (FC1), und dieses ruft einen Motorbaustein auf (FB10). Der Fehler passiert im FB10.
Die aufruf_liste enthält dann den ganzen Weg: [OB1, FC1, FB10]. Da wir genau wissen wollen, wo es geknallt hat, brauchen wir den allerletzten Eintrag der Liste
1
. In Python greift man mit der Position [-1] ganz elegant immer auf das exakt letzte Element einer Liste zu (egal wie lang sie ist)
1
.
.filename und .lineno: Das sind jetzt die fertigen, sauberen Variablen
1
. script_name ist jetzt ein reiner Text (String) wie "C:/programme/mein_script.py" und zeile ist ein waschechter Integer (Zahlenwert) wie 14. Perfekt, um sie einzeln an einen SQL-Query für deine Logger-Datenbank zu übergeben.
kopiert von ner AI. Als Notiz wie und was (ungefähr...)