NO IMAGEThe Rust Programming Language 日本語版 - The Rust Programming Language 日本語版
を読んでいる

昨日はサボってしまった。だから部屋が汚いのはよくない。
やむを得ない事情でスチールラックが倒壊したのでしかたないが、早く整理を終えたい。

• https://doc.rust-jp.rs/book-ja/ch09-02-recoverable-errors-with-result.html#エラー委譲のショートカット-演算子
• 今ここを読む

エラー処理の続き

多くのエラーは、プログラムを完全にストップさせるほど深刻ではありません。時々、関数が失敗した時に、 容易に解釈し、対応できる理由によることがあります。

• たしかにそう
• ちゃんと勉強するとこういうあたり前の問いも必要になってゆくんだな
• ここ良くよんだら前回やったな
• エラー委譲のショートカット: ?演算子
  • おそらく次はここ

    Result値の直後に置かれた?は、リスト9-6でResult値を処理するために定義したmatch式とほぼ同じように動作します。 Resultの値がOkなら、Okの中身がこの式から返ってきて、プログラムは継続します。値がErrなら、 returnキーワードを使ったかのように関数全体からErrの中身が返ってくるので、 エラー値は呼び出し元のコードに委譲されます。

use std::fs::File;
use std::io;
use std::io::Read;

fn read_username_from_file() -> Result<String, io::Error> {
    let mut f = File::open("hello.txt")?;
    let mut s = String::new();
    f.read_to_string(&mut s)?;
    Ok(s)
}

• ふむ
• enumのmatchを書かなくて良くなると
• 基本こっちを書いて、特殊な処理が必要な時はmatchを書く
  • matchだと式なので柔軟性がある、なるほどー

use std::fs::File;
use std::io;
use std::io::Read;

fn read_username_from_file() -> Result<String, io::Error> {
    let mut s = String::new();

    File::open("hello.txt")?.read_to_string(&mut s)?;

    Ok(s)
}

リスト9-8: ?演算子の後のメソッド呼び出しを連結する

sの新規Stringの生成を関数の冒頭に移動しました; その部分は変化していません。変数fを生成する代わりに、 read_to_stringの呼び出しを直接File::open("hello.txt")?の結果に連結させました。 それでも、read_to_string呼び出しの末尾には?があり、File::openとread_to_string両方が成功したら、 エラーを返すというよりもそれでも、sにユーザ名を含むOk値を返します。機能もまたリスト9-6及び、9-7と同じです; ただ単に異なるバージョンのよりエルゴノミックな書き方なのです。

• ????
• ここ日本訳おかしい気がする
• まあでも言いたいのは関数型言語のように処理が終了したのちに次の.を評価するとかそんなんだろう
• 理解した、正常系の場合のみ次の処理にいくんだな

?演算子はResultを返す関数でしか使用が許可されないと指摘しています。

• そりゃそうか、必ずResult型で返すって発想が偉いな

• panic!すべきかするまいか

  • これに入った

    稀な場面では、Resultを返すよりもパニックするコードを書く方がより適切になることもあります。

  • まーこれだよね、気になるのは

  • やばい、ここ日本語訳怪しいな

• Resultが返ってくるメソッドにはprefixに?を使うとResultのenumのmatchを省略できる
• 詳細に書きたいときはmatchを細かく書いて処理を分けよう
• Resultってよく考えられてるなーと再度感動

• コンパイラよりもプログラマがより情報を持っている場合