stringの限界これまで、エラーの値としてStringをしばらく使用してきました。実のところ、これはエラーとして用いるには限界があります。以下に良いエラー型であるための条件を挙げます。Stringは1つめと2つめの条件はいい感じに満たしてくれるのですが後の2つは満たしません。異なるエラーを一つの型で表現できる。ユーザーに綺麗なエラーメッセージを見せてくれる。容易に型比較ができる。以下の二つの型を比較することを考えてみましょう。Err("少なくとも一つの要素を持つベクタを使用してください".to_owned())Err(EmptyVec)エラーの内容に関する情報を持つことができる。以下の二つを比べてください。position))このことから、Stringをエラーとして用いると、エラーの対処・明示的な作成という点が困難になります。実際のところ、たとえエラーメッセージの見た目がいい感じであったとしても、それはそのエラーの型の構造とは何の関係もありません。その型に対するDisplayの実装のみに依存するからです。単純にいい感じのエラーメッセージを表示したいという目的のためにStringを操作するコードを書くと、どうしてもコードベースが複雑になって汚染されてしまいますので、その必要はありません。独自のエラー型を定義する。自由にカスタマイズできる。独自に定義したエラー、あるいはその両方に従うことが可能となる。このエラーに関しては、エラーの詳細を説明するのに追加の情報は必要ない。パースに失敗した場合はParseIntErrorの挙動に追従する。場合は、この型に、より多くのデータを追加しなくてはならない。型がどのように表示されるかは、そのエラーが生じた場所とは全く関係がない。そのままぶちまけられてしまうことも心配する必要はない。ここではエラーに関して、追加の情報を保持してはいない。どれであるかを明示したいとする。保持するようにしてやる必要がある。こちらはラッパーなので、内側の型(この場合は`ParseIntError`)の`fmt`の実装に従う。ここでも新しいエラー型へとアップデートさせる。also:Result、io::Result。