/* Page prose (de) */
"WhereBugsHide" = "# Zähle die Stellen, an denen sich ein Bug verstecken kann\n\nDieses eine Ergebnis auf dem glücklichen Pfad verbirgt viele Wege, Pech zu haben. Geh den Code durch und zähle sie:\n\n* **Die Verschachtelung selbst.**  \nDrei Schritte, drei Einrückungsebenen, und die eigentliche Logik („die Broschüre binden\") sitzt am weitesten rechts, am schwersten zu finden. Das ist die **Pyramide des Verderbens**: eine Aufrufstruktur, die mit jedem abhängigen Schritt seitwärts wächst.\n* **Drei getrennte Fehlerpfade.**  \nJedes `.failure` muss daran denken, `completion(.failure(error))` aufzurufen. Verpasst du eines, verschwindet dieser Fehler stillschweigend; die Fertigstellung des Aufrufers wird einfach nie aufgerufen.\n* **Die leicht zu übersehende Fertigstellung.**  \nEs gibt keine Compiler-Regel, die sagt „du musst `completion` auf jedem Pfad aufrufen.\" Füge einen vierten Zweig hinzu, vergiss den Callback, und die Seite hängt für immer ohne Fehler.\n* **Das Einfangen von `self`.**  \nWeil ein Handler die Funktion überlebt, die ihn gestartet hat, kann das starke Einfangen von `self` die `PrintShop`-Instanz länger am Leben halten als beabsichtigt. Wir haben `[weak self]` geschrieben, aber *daran zu denken* und es richtig zu machen, ist manuell.\n* **Der Sprung zum Hauptthread.**  \n`bindBooklet` meldet auf einer Hintergrund-Warteschlange. Wir haben `DispatchQueue.main.async` hinzugefügt, damit eine UI-Aktualisierung sicher wäre. Vergiss es, und du bekommst einen Bug, der sich nur *manchmal* daneben benimmt, die schlimmste Sorte zum Aufspüren.\n\nNichts davon ist exotisch. Jedes ist ein ganz normaler Dienstag in einer Closure-basierten Codebasis. Das Modell ist nicht *falsch*; es macht Korrektheit nur an jeder Naht zu *deiner* Verantwortung.\n\n[Zurück](@previous)  |  Seite 4 von 6  |  [Weiter: Derselbe Auftrag, neu geschrieben](@next)";
