std::num::ParseIntError)に対してmapし、自身で定義したカスタムエラー型に変換したのを見ました。.map_err(DoubleError::Parse)これはとてもシンプルで一般的なオペレーションなので、もし取り除くことができたら便利なのですが、悲しいかなそうするとうまく動作しません。and_thenではフレキシビリティが足りなくてこのケースには対処できないのです。try!ならば可能です。Err(err)のどちらか」であると説明しました。これは93%の正しさでしかありません。Err(From::from(err))のどちらか」です。From::fromは異なる型同士の変換をおこないます。これはつまり、何かをtry!した際にエラーが生じ、そのエラーが返り値の型へと変換可能な場合、自動的に変換するということを意味します。従って、この例をtry!マクロを用いて書き直し、From::fromを我々のエラー型に対して実装すれば、map_errをなくすことが可能になるということを意味します。`ParseIntError`から`DoubleError`への変換を実装する。変換する必要があれば自動的に実行される。中の値を取り出すことに`try!`している。}これで大分綺麗になりました。元々のpanicしていたものと比べると、unwrapの呼び出しがtry!で置き換えられているという点で非常に似たものとなっています。違いは、返り値がResultなのでトップレベルで中身を取り出す必要があるという点です。実践上は、このようなエラーハンドリングによってunwrapの使用が全くなくなるということはないでしょう。いうのも、ここではエラーハンドリングの仕方により、コードの行数が3倍になっています。全体のコード量の少なさを考慮に入れてもなお、これはとてもシンプルと呼べるものではありません。いえ、1000行のコードからなるライブラリでは、100行追加することによりunwrapからより洗練されたエラーハンドリングに移行するのは、十分にリファクタリングの価値があることです。これは非常に理にかなった対処法です。ほとんどのライブラリでは、Displayを追加し、必要に応じてFromを追加するだけで、unwrapをなくすことができます。真剣に作られたライブラリの場合、ユーザーがどのようにエラーを扱うかに対してある程度想定しておくべきです。そのような場合、エラーハンドリングはもう一歩進んだやり方をする必要があります。also:From::from、try!。