レッスン

try ? が throws をオプショナル ( T ?) の世界にどう変換するのかを見ていきます。つまり、エラーを「単に値がない」とみなしてよい場面はいつなのか、 try ? を if let/ guard let や演算子 ?? とどう組み合わせるのか、なぜエラーの理由が重要な場合があるのか（そのときは do/ catch が必要です）、そして「静かな」エラー抑制がコードの保守性を損なう典型的なミスについて学びます。

try ! が「便利な省略」ではなく、「エラーは起きない」という厳しい契約である理由を解説します。 runtime trap とは何か、 throw が起きるとアプリがなぜ異常終了するのか、 try、 try ?、 do / catch がどのように制御を保つのか、そして try ! が（まれに）適切になるのはどこか、主に完全に制御されたリテラルの場合です。

同じエラーでも、ほとんど常に 2 つの対象があることを解説します。ひとつはユーザー、もうひとつは開発者です。そして、それらを 1 つの出力に混ぜないようにする方法を学びます。Swift 向けの実践的なテンプレートを作りましょう。型は AppError ひとつでも、面は 2 つあります。UX 向けの userMessage と、診断用の debugMessage です。さらに、 print ( error ) がなぜほとんど常に悪い UX なのか、またアプリケーションの境界で throw を do/ catch でどう正しく処理するのかも見ていきます。

Swift における実践的なエラー処理を解説します。アプリ全体で 1 つの共通な Error にまとめると、なぜデバッグや UX が難しくなるのか、エラーを層ごとに分ける方法（ ParseError、 DomainError、 StorageError、 NetworkError）、それらを AppError という上位レベルのエラーへ do/ catch で変換する方法、そして CLI フローのどこでエラーを捕捉するのがよいかを扱います。LibraryCLI を例に、 parse → domain → storage という流れを構築し、よくあるミス（たとえば try ? の乱用）についても আলোচনাします。

Swift におけるエラーの「二重チャネル」デザインを解説します。ユーザー向けの個別メッセージ ( userMessage) と、診断用の個別メッセージ ( debugMessage) を分けて持ちます。 CustomStringConvertible を使って便利な出力を追加し ( print で役立つログが表示されるようにするため)、さらに localizedDescription とプロトコル LocalizedError を通じて標準の仕組みにきれいに統合します。 LibraryError の例では do/ catch での処理を示し、文字列でロジックを組むべきではない理由も説明します。