Rust by Example

16.9 try!再入門

前項の例では、parseを呼び出した直後に、生じたライブラリのエラー(訳注: std::num::ParseIntError)に対してmapし、自身で定義したカスタムエラー型に変換したのを見ました。

.and_then(|s| s.parse::<i32>()
    .map_err(DoubleError::Parse)

これはとてもシンプルで一般的なオペレーションなので、もし取り除くことができたら便利なのですが、悲しいかなそうするとうまく動作しません。and_thenではフレキシビリティが足りなくてこのケースには対処できないのです。しかしtry!ならば可能です。

以前、try!マクロは「unwrapreturn Err(err)のどちらか」であると説明しました。これは93%の正しさでしかありません。正確には「unwrapreturn Err(From::from(err))のどちらか」です。From::fromは異なる型同士の変換をおこないます。これはつまり、何かをtry!した際にエラーが生じ、そのエラーが返り値の型へと変換可能な場合、自動的に変換するということを意味します。従って、この例をtry!マクロを用いて書き直し、From::fromを我々のエラー型に対して実装すれば、map_errをなくすことが可能になるということを意味します。

use std::num::ParseIntError; use std::fmt; type Result<T> = std::result::Result<T, DoubleError>; #[derive(Debug)] enum DoubleError { EmptyVec, Parse(ParseIntError), } // `ParseIntError`から`DoubleError`への変換を実装する。 // これは`try!`が呼ばれた際に`ParseIntError`が`DoubleError` // に変換する必要があれば自動的に実行される。 impl From<ParseIntError> for DoubleError { fn from(err: ParseIntError) -> DoubleError { DoubleError::Parse(err) } } impl fmt::Display for DoubleError { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { match *self { DoubleError::EmptyVec => write!(f, "please use a vector with at least one element"), DoubleError::Parse(ref e) => e.fmt(f), } } } // 前と同じ構成だが、全`Result`と`Option`をチェインしていく代わりに、 // いきなり中の値を取り出すことに`try!`している。 fn double_first(vec: Vec<&str>) -> Result<i32> { // Still convert to `Result` by stating how to convert `None`. let first = try!(vec.first().ok_or(DoubleError::EmptyVec)); let parsed = try!(first.parse::<i32>()); Ok(2 * parsed) } fn print(result: Result<i32>) { match result { Ok(n) => println!("The first doubled is {}", n), Err(e) => println!("Error: {}", e), } } fn main() { let numbers = vec!["93", "18"]; let empty = vec![]; let strings = vec!["tofu", "93", "18"]; print(double_first(numbers)); print(double_first(empty)); print(double_first(strings)); }

これで大分綺麗になりました。元々のpanicしていたものと比べると、unwrapの呼び出しがtry!で置き換えられているという点で非常に似たものとなっています。違いは、返り値がResultなのでトップレベルで中身を取り出す必要があるという点です。

しかし実践上は、このようなエラーハンドリングによってunwrapの使用が全くなくなるということはないでしょう。というのも、ここではエラーハンドリングの仕方により、コードの行数が3倍になっています。全体のコード量の少なさを考慮に入れてもなお、これはとてもシンプルと呼べるものではありません。とはいえ、1000行のコードからなるライブラリでは、100行追加することによりunwrapからより洗練されたエラーハンドリングに移行するのは、十分にリファクタリングの価値があることです。

これは非常に理にかなった対処法です。ほとんどのライブラリでは、Displayを追加し、必要に応じてFromを追加するだけで、unwrapをなくすことができます。ただ、真剣に作られたライブラリの場合、ユーザーがどのようにエラーを扱うかに対してある程度想定しておくべきです。そのような場合、エラーハンドリングはもう一歩進んだやり方をする必要があります。

See also:

From::fromtry!