マクロを使うと、最後の例をシンプルにすることが、とても簡単にできます。場合分けと早期リターンを肩代わりしてくれますので、コードが締まって読みやすくなります。変換しなければならないからです。いい知らせがあります。省く前に、標準ライブラリのいくつかの重要なトレイトについて、もう少し学ぶ必要があるということです。使用を取り除くことで、この節を締めくくりたいと思います。便利に使ってきました。エラーは簡単に文字列へ変換できますし、問題が起こったその場で、文字列によるエラーを新たに作ることもできるからです。使ってエラーを表すことには欠点もあります。ひとつ目の欠点は、エラーメッセージがコードのあちこちに散らかる傾向があることです。エラーメッセージをどこか別の場所でまとめて定義することもできますが、特別に訓練された人でない限りは、エラーメッセージをコードに埋め込むことへの誘惑に負けてしまうでしょう。その通りのことをしました。全てのエラーを文字列に変換してしまったら、呼び出し元に渡したエラーが、オペーク(不透明)になってしまいます。エラーに対してできる唯一妥当なことは、それをユーザーに表示することだけです。文字列を解析して、どのタイプのエラーだったか判断するのは、もちろん強固なやり方とはいえません。(この問題は、ライブラリの中の方が、他のアプリケーションのようなものよりも、間違いなく重大なものになるでしょう。IO操作において何が失敗したのかを示します。エラーによって違った対応を取りたいこともあるので、このことは重要です。エラーはエラーコードと共に異常終了して、ユーザーにエラーを表示することを意味するかもしれません。呼び出し元でエラーの種類を調査するために、場合分けが使えます。中からエラーの詳細がなんだったのか探りだすことよりも、明らかに優れています。よってエラー内容を表すことができます。呼び出し元が詳細を検査したいときに備え、大元のエラーについての情報を取りこぼさないよう、努力してみましょう。使って独自の直和型を定義することです。