/* Page prose (ja) */
"WhereBugsHide" = "# バグが潜める場所を数える\n\nあの一つのハッピーパスの結果は、不運になり得る多くの道を隠しています。コードをたどって、それらを数え上げてみましょう。\n\n* **入れ子そのもの。**  \n三つのステップ、三段階のインデント、そして本当のロジック（「冊子を綴じる」）が最も右に位置し、最も見つけにくくなっています。これが**破滅のピラミッド**です。依存するステップが増えるたびに横へ伸びていく呼び出し構造です。\n* **三つの別々のエラー経路。**  \nそれぞれの `.failure` は `completion(.failure(error))` を呼ぶことを忘れずにいなければなりません。一つでも見落とすと、その失敗は静かに消え去り、呼び出し元の完了処理はまったく呼ばれません。\n* **見落としやすい完了処理。**  \n「すべての経路で `completion` を呼ばなければならない」というコンパイラの規則はありません。四つ目の分岐を加え、コールバックを忘れれば、ページはエラーもなく永遠にハングします。\n* **`self` のキャプチャ。**  \nハンドラーはそれを開始した関数よりも長く生き残るため、`self` を強くキャプチャすると、`PrintShop` を意図より長く生かし続けてしまうことがあります。私たちは `[weak self]` と書きましたが、それを*忘れずに*、かつ正しく行うのは手作業です。\n* **メインスレッドへの移動。**  \n`bindBooklet` はバックグラウンドキューで結果を返します。UI の更新が安全になるように `DispatchQueue.main.async` を加えました。それを忘れると、*ときどき*しか誤動作しないバグを抱えることになり、追跡するのに最悪の種類のものです。\n\nこれらのどれも珍しいものではありません。どれも、クロージャベースのコードベースではありふれた日常です。モデルが*間違っている*わけではありません。ただ、あらゆる継ぎ目で正しさを*あなたの*責任にしているだけです。\n\n[前へ](@previous)  |  4 / 6 ページ  |  [次へ: 同じジョブ、書き直し](@next)";
