Rust part19

1 名前：デフォルトの名無しさん mailto:sage [2023/01/17(火) 12:41:32.25 ID:nikBFIMQ.net] 公式 https://www.rust-lang.org/ https://blog.rust-lang.org/ https://github.com/rust-lang/rust 公式ドキュメント https://www.rust-lang.org/learn Web上の実行環境 https://play.rust-lang.org ※Rustを学びたい人はまず最初に公式のThe Bookを読むこと https://doc.rust-lang.org/book/ ※Rustを学ぶ際に犯しがちな12の過ち https://dystroy.org/blog/how-not-to-learn-rust ※Rustのasyncについて知りたければ「async-book」は必読 https://rust-lang.github.io/async-book/ ※次スレは原則>>980が立てること 前スレ Rust part18 https://mevius.5ch.net/test/read.cgi/tech/1670663822/ 101 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 07:18:58.36 ID:ksaPk66E.net] て言うか>>99は前半と後半で矛盾してるしアホほど長文を証明してるw 102 名前：デフォルトの名無しさん [2023/01/29(日) 11:17:47.92 ID:p51Kojpz.net] panicは仕様に書いてなければバグでしょ どんなプログラム書いてんだよ 103 名前：デフォルトの名無しさん [2023/01/29(日) 11:27:06.90 ID:FaEg6ckP.net] エラーハンドリングという言葉をpanicをハンドリングしてResultにすることだと思ってたのか そりゃ噛み合わないわな 104 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 13:10:21.68 ID:ZDOIjMr/.net] 例えばpythonのexitの代用としてpanicを使ったところで何の問題もない 105 名前：デフォルトの名無しさん [2023/01/29(日) 14:45:33.86 ID:ttNbSKVN.net] 問題ありまくり 同じexitがあるのにわざわざpanicで代用するメリットは何？ 106 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 15:29:55.13 ID:yzACUqHq.net] まずは異常終了と正常終了を分断するメリットを知る必要がある 107 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 15:33:47.16 ID:ZDOIjMr/.net] >>105 へー今初めて知った The BookのCommon Programming Conceptsあたりにそれっぽい記述はないし 中断したければpanicするしかないと思っていたよ 後学のためにどこで解説されているのか教えてほしいな 108 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 15:48:49.58 ID:CZoRokqJ.net] panic!すべきかするまいか https://doc.rust-jp.rs/book-ja/ch09-03-to-panic-or-not-to-panic.html 109 名前：デフォルトの名無しさん [2023/01/29(日) 17:07:54.00 ID:qjfBPBdR.net] >>107 The Bookの12章を復習して https://doc.rust-lang.org/book/ch12-00-an-io-project.html ただThe Bookは他言語から来た人が最初に読むチュートリアルとして用意されてるものなのでカバーされてない内容も多々あるし深い解説がされてるわけでもない点は理解しておいた方がいいよ 110 名前：はちみつ餃子 mailto:sage [2023/01/29(日) 17:16:49.84 ID:2OIx0YXk.net] 標準ライブラリのマニュアルでも panic! はバグを説明するために使うということは書いてあるね。 https://doc.rust-lang.org/std/macro.panic.html 111 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 18:20:40.83 ID:yP5ym/xP.net] >>107 exitはプロセスの終了状態コードを伝えることを兼ねたOSシステムコールだから通常の言語には必ずある そしてそのことを分かっていればRust初心者であってもstd::process::exitをすぐに見つけられる 112 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 18:41:07.89 ID:qSgQK/Ke.net] >>105 Pythonのsys.exitと同じ感覚でstd::process::exit使うほうがはるかに問題では？ 少なくとも異常終了に使う分にはpanic!のほうがsys.exitに近いと思うよ sys.exit() https://docs.python.org/3/library/sys.html#sys.exit ・SystemExit例外を投げるだけ ・メインスレッドで実行して、かつ例外がトップレベルまで捕捉されなければ、通常の例外機構に従ってプロセスが終了する →finallyとかwithでリソース解放書けばちゃんと解放される std::process::exit() https://doc.rust-lang.org/std/process/fn.exit.html ・無条件でプロセスを終了させる ・実行スレッドも他のスレッドも一切スタック巻き戻しが行われない →デストラクタ呼ばれない 113 名前：デフォルトの名無しさん [2023/01/29(日) 18:45:14.86 ID:jE2G9ZiM.net] _exit()はシステムコールだけどexit()はライブラリの関数 pythonのexit()やsys.exit()は基本的にexitcodeを設定してSystemExit例外を投げてるだけ os._exit()がprocess::exit()に近い 114 名前：デフォルトの名無しさん [2023/01/29(日) 18:46:31.90 ID:jE2G9ZiM.net] >>112 例外のある言語と同じ感覚でプログラミングするのが一番の問題 それ抜きにpythonと比べとも意味ないよ 115 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 18:48:13.88 ID:yP5ym/xP.net] 一般的な他の言語におけるtry-throw-catchの機能が欲しいならば それはRustやGoなどでは意図的に排除されていて存在しない RustではResultで返すだけでよく利便性と効率を両立させている 116 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 19:53:25.69 ID:ZDOIjMr/.net] >>109 そこは見ているけど制御機構を説明しているところで同時に解説すべきなのでは >The Bookは他言語から来た人が最初に読むチュートリアルとして用意されてるもの なおさら他言語でメジャーな機能や実装と対比した解説が必要では >>112 unwind不可なのは使いにくい場面が少なからずありそう 今作っているのはdrop使っているから強制abortは問題しかない 117 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 21:27:11.45 ID:yzACUqHq.net] RustのdropにはRcという具体的な目的がある Rcが完璧主義ではないのでdropも完璧にする必要を感じない 118 名前：デフォルトの名無しさん [2023/01/29(日) 21:32:58.27 ID:ns31yZLJ.net] >>112 >Pythonのsys.exitと同じ感覚でstd::process::exit使うほうがはるかに問題では？ RustではResultをmainまで戻してからprocess::exitする Pythonは例外という仕組みでランタイムがそれをやってくれる panicはやってることがにてるからという理由で使うようなものじゃない 119 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 21:46:05.85 ID:hfoWSJ8/.net] >>115 そうではないよ？例えばrustの標準ライブラリのTcpStreamにはset_read_timeoutでタイムアウトを設定すると、それ設定値以上でpanicを起こす。 これは通信中に非同期制御やスレッド監視などをしないための苦肉の策でResultをmatchするだけという考えから外れて、回復不能としているのだがリードタイムアウトであろうと再試行するようなプログラムではpanicを考慮しなければならない。 一方でTcpStreamの多くはResult<>を返すので、高度なプロトコルを作るような場合、受け取ったデータなどを調べてpanicさせる方法などが公式ドキュメントにも述べられている。 120 名前：デフォルトの名無しさん [2023/01/29(日) 21:46:28.34 ID:6XW+IoFB.net] The Bookに書いてるようにpanicを使う対象となるような回復不可能なエラーは常にバグによるもの Rust groups errors into two major categories: recoverable and unrecoverable errors. Unrecoverable errors are always symptoms of bugs. 121 名前：デフォルトの名無しさん [2023/01/29(日) 21:56:31.01 ID:saQmfbkd.net] >TcpStreamにはset_read_timeoutでタイムアウトを設定すると、それ設定値以上でpanicを起こす。 readで設定したtimeout値を超えたらpanicすると言ってる？ 少なくともリファレンスにはResultが返されるとあるんだが 122 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 21:57:37.90 ID:K3YIwpIF.net] >>113 _exitはexit_groupのラップ関数だよ 123 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 22:09:10.65 ID:+VDCQEdm.net] 言語の理想と実装は違うから食い違いが出ている。現実的には作者がめんどくさくなったり、ライブラリとそれを利用するレイヤーの区別があいまいな場合などに大域脱出とスタック巻き戻しがしたいだけで回復可能な場合にもpanicを投げてしまう実装もありうるのでバグではない。標準ライブラリでさえそうなのだから 124 名前：デフォルトの名無しさん [2023/01/29(日) 22:14:20.10 ID:jL8Axswy.net] > 受け取ったデータなどを調べてpanicさせる方法などが公式ドキュメントにも述べられている。 これはpanicを使えということじゃなくサンプルコードとしての簡潔さ優先してるだけ 改善はされてきてるけどunwrapがあちこちにあるのと同じ 箸の上げ下げレベルで手取り足取り教えてもらうことを期待し過ぎじゃないか 125 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 22:21:53.21 ID:qSgQK/Ke.net] >>118 うん別に良いデザインではないよ、そこは同意する 俺は「同じexitがあるのに」という表現が招きかねない誤解に釘を差しただけです 126 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 22:33:36.00 ID:+VDCQEdm.net] >>124 もちろんドキュメントで述べられてる通り、Resultが一番の選択肢で回復可能で返せるのにpanicを使うのは愚策でしょう。だから理想はとそういってますよね？ 手取り足取り教えてもらうのはどちらなのかというよりも、どうしてもpanicで終了はバグだという理想・意見をとゴリ押ししたいだけに見えます。 これは（＝回復可能なのに）panicを使えということじゃなくというのは強く同意ですが、そうなっていないものを使用している現実があるという話でpanicを書いてないことに期待し過ぎじゃないか？ということになります 127 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 22:38:36.38 ID:yP5ym/xP.net] >>119 Rustでそのような形のpanicの使われ方はしませんしpanicは起きません タイムアウトもio::Resultでio::Errorが返るだけです これはC言語で書いてSO_RCVTIMEOでタイムアウト値を設定してreadで-1とerrnoが返る時と全く同じ状況です 言語独自の例外機構を持つ言語は複雑にしてややこしくしているだけなのでその考えをまず捨てるところからスタートしましょう 128 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 22:44:10.80 ID:yP5ym/xP.net] >>126 今回のケースでも標準ライブラリはpanicを起こしていませんしpanicを起こす仕様はありません もしpanicが起きたのならばそれはあなたがResultの処理をせずに強引にunwrap()したためであり あなたのコードがpanicを引き起こしたのです 129 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 22:49:39.52 ID:ZDOIjMr/.net] The BookにmainまでResultで戻す実践的な設計方法って解説されてる？ 機能の説明はあっても実装するうえでどのようにしたらいいのかってところは抜けているような ググるとstd::num::*を返す例、Stringを返す例、enumを返す例などが出てくるが どのように使い分ければいいのかって点は不明 このスレ見ていてもこの部分に関する資料を提示している人は見かけないし >>124 >箸の上げ下げレベルで手取り足取り教えてもらうことを期待し過ぎじゃないか 箸文化圏なら要らないだろうがスプーン・フォーク文化圏なら要るんじゃね 他所と大きく違うのであれば十分な説明を求められるのは当然では 130 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 22:51:25.05 ID:CZoRokqJ.net] > 例には、不正なデータを渡されたパーサとか、 訪問制限に引っかかったことを示唆するステータスを返す > HTTPリクエストなどが挙げられます。 このような場合には、呼び出し側が問題の処理方法を決定できる > ようにResultを返してこの悪い状態を委譲して、 失敗が予想される可能性であることを示唆するべきです。 > panic!を呼び出すことは、 これらのケースでは最善策ではないでしょう。 131 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 23:19:15.93 ID:B9jwmLl6.net] >>129 mainまでResultで戻すにはResult型を返す関数を書くだけ 何も難しいことはなく複雑なこともなくシンプル Resultは単なる型の一つでOk値とErr値のEnumに過ぎない Rust言語はResultに対し例外機構のような特別扱いをしていない ResultはTryをimplしてるから『？』オペレータを適用できるなどくらいしか他の型との違いはない したがって新たに勉強すべき点はそこだけだが『？』は使わずとも同じことを記述することができる 132 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 23:31:48.93 ID:ZDOIjMr/.net] >>131 Result<T, E>のEってなしに出来たっけ？自分が言いたいのはそういう話なんだけど 133 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 23:45:24.52 ID:B9jwmLl6.net] >>132 特別扱いはないので自由 例えばbool相当としてResult<(),()>型を使ってももちろん機能する またOption<T>相当としてResult<T,()>型 通常はそれぞれ前者を使って必要なところで初めてResultへ変換が普通 134 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 23:50:28.46 ID:X9CS5Y/7.net] >>129 > The BookにmainまでResultで戻す実践的な設計方法って解説されてる？ 12章はどうだろうか、minigrep を作るところ 135 名前：デフォルトの名無しさん [2023/01/29(日) 23:59:14.71 ID:/s+aPXiv.net] >>129 12章に書いてるでしょ それに一連のレスで書いてる設計指針はRust特有の話じゃないよ アプリのトップレベルに集約エラーハンドラを用意するのは例外機構のある他の言語でも同じだし エラー発生時にexitcodeを設定してプロセス終了させるのはUIに相当するレイヤーの仕事だからそこまで戻してハンドリングするのも他の言語でも同じ pythonだとしてもいろんなレイヤーでsys.exitするのは典型的なダメなやり方 136 名前：デフォルトの名無しさん mailto:sage [2023/01/29(日) 23:59:23.38 ID:B9jwmLl6.net] RustはResultを特別視しない 例えばGoのようにRustで(正常値, エラー値)とタプルで返す関数群でプログラミングしても同様に動く じゃあなぜResultを用いるのか？ ・統一した型があった方がいい ・二値ではなく二種のEnumでよい ・便利なメソッド群を標準で用意できる ・標準ライブラリをResultで統一できる 137 名前：デフォルトの名無しさん [2023/01/30(月) 00:00:50.47 ID:M6Z3pSeY.net] すまん被ってた 138 名前：デフォルトの名無しさん [2023/01/30(月) 00:02:36.60 ID:RUd1b+83.net] >>132 なんでEを無くしたいの？ 139 名前：デフォルトの名無しさん [2023/01/30(月) 00:09:50.85 ID:Oa/BEQbJ.net] Rust特有のエラーハンドリングの実践的な知識はanyhow/thiserrorの使い方を学ぶといい それらのcrateを使わず自前でやるとしても何を用意する必要があるのかわかる 140 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 00:14:09.92 ID:q9Kf6jE6.net] 副作用がない関数なら大域脱出を使うべきでないのは分かる 副作用に寛容で大域脱出に不寛容なのは分からん 141 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 00:19:52.36 ID:1Kzq/YqA.net] >>139 それは初心者には混乱の元 panicとか言ってる初心者たちが最初にすべきことは一つ 「unwrap()を使わずにプログラムを書く」 142 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 08:11:22.12 ID:sNrNLjHp.net] >>109 >The process::exit function will stop the program immediately and return the number that was passed as the exit status code. >This is similar to the panic!-based handling we used in Listing 12-8, but we no longer get all the extra output. >・・・ >Great! This output is much friendlier for our users exitの使用目的はpanicによる不必要なメッセージの抑制に読めるけど？>>112で触れられている副作用なんか完全スルー それに明らかに大域脱出を意図した使い方 裏を返せばpanicのメッセージ出力が問題にならないのであればpanicでも構わないとも取れる 143 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 08:21:18.23 ID:e4IM4WvI.net] もういいよ。お前はずっとpanic使っとけ。 144 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 08:28:01.11 ID:1Kzq/YqA.net] Rustをきちんと学ぶ気があるならば まずはpanicもunwrapも使わずにプログラムを自在に書けるようになること そういう基礎ができていないから勘違いしてpanicにこだわろうとしてしまう 145 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 08:31:46.93 ID:uyNTp5VX.net] 評判の悪いthe book 日本語版にすら使い分けの記述あるのに、それを無視して回復不能なエラー処理以外でpanicを推奨しようとするのは何なのかね。 エラー処理 Rustには例外が存在しません。代わりに、回復可能なエラーにはResult<T, E>値があり、 プログラムが回復不能なエラーに遭遇した時には、実行を中止するpanic!マクロがあります。 146 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 08:40:51.18 ID:VdE13u+1.net] the bookを一通りきちんと読んだならunwrapは極力使うべきではないものだと理解できるはずなんだけどな 147 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 11:00:50.02 ID:R3gVBmE3.net] >>138 panicで大域脱出して構わない状況ならmainで必要な情報はreturnするか否かだけ これはResultが保持しているのでEは不要 148 名前：デフォルトの名無しさん [2023/01/30(月) 11:23:44.77 ID:hiS6eSAP.net] >>147 すまんけど全然わからない TとEの両方がないとResultが存在できないと思うんだが 149 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 11:26:30.09 ID:q36OfC0i.net] TとEを()にしたら実質ないなので 150 名前：デフォルトの名無しさん [2023/01/30(月) 11:36:33.64 ID:2ZbeByHM.net] >>142 ちゃんと読もう そして全体の文脈を理解しよう https://doc.rust-lang.org/book/ch12-03-improving-error-handling-and-modularity.html#fixing-the-error-handling 151 名前：デフォルトの名無しさん [2023/01/30(月) 11:50:16.61 ID:xWvH9QlK.net] >>149 Eをunit typeにすることをEをなしにすると言ってることは理解したが >panicで大域脱出して構わない状況ならmainで必要な情報はreturnするか否かだけ これは全然わからない 大域脱出したいからpanic使いたがってるという動機部分は理解した 152 名前：デフォルトの名無しさん [2023/01/30(月) 12:08:29.21 ID:xWvH9QlK.net] exitcodeをちゃんと実装したい時は process::exitのリファレンスに書いてるように mainの戻り値にTerminationを実装した型を指定してprocess::exitは使わずmainから戻り値を返す方法が今は推奨 153 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 12:56:41.01 ID:WhTmZ0y4.net] >>151 処理継続不能なら終了するしかないからね。panicで終了しようが、mainまで戻ってからreturnしようが大差ない 154 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 19:01:04.95 ID:uxYUj7Ri.net] >>153 いやいや、深いところから脱出するのにResultだと途中の階層すべてで返さないとダメだからコーディングの手間が全然違うだろ 155 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 19:07:00.52 ID:6jXELBYF.net] >>154 でもアンチpanic君？はその手間を正当化したいっぽいじゃん 156 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 19:15:25.77 ID:mQYOoXSo.net] 日曜プログラマーの作るソフトときちんと作るソフトで基準がズレてる感じ 157 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 19:23:44.43 ID:mT8msQLw.net] そうやってすぐ人格の問題にする 158 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 19:39:30.35 ID:dHwZCroo.net] >>154 実際にコーティングしてみれば手間はほぼないと分かる ・返り値型をResult<>で括る ・ライブラリも自作もResult返す関数を上位へスルーするなら「?」を後置 たったこれだけの話 もちろんその場で処理したいResultや情報を増やしたいResultは今回の話以前に元々処理しているはず 回復不能なエラーなんて滅多に起きず ほとんどはその場か上位関数で何らかの対応処理するエラーなのだから panicは滅多に必要としない 159 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 19:54:44.86 ID:kIeP1yzV.net] mainまで戻るってことはmain肥大化と同義。積極的にmainを複雑化させるべきいう主張か もちろんプログラミングの定石的には1関数にあれもこれも詰め込むのは悪手だよな panicダメ言っている人は実用的なプログラムを書いたことがあるのだろうか 160 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 19:54:52.38 ID:uxYUj7Ri.net] >>158 > たったこれだけの話 それを途中の階層全てでやらんとダメだろ お前こそでかいプログラム組んだことないんじゃね？ そもそも途中の階層は自分が組んでるとは限らんし 161 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 20:06:49.02 ID:Lj/9/9R5.net] デストラクタ内でexitを使ってはいけない デストラクタ内で利用可能な関数の中でexitを使ってはいけない すべての関数はexitを使ってはいけない こういうことかな 162 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 20:18:26.31 ID:TH7lLy8N.net] なんかめっちゃ盛り上がってて草 163 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 20:21:20.63 ID:J7344Opw.net] そもそもPythonのsys.exitだって本当は100点満点の正解コードを目指すなら独自例外作れって話だし その程度の雑さでいいならRustでも雑にpanicしたっていいじゃない 教科書的な話じゃなく、もっと実利的な問題が何かあるなら教えてくれよ 164 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 20:22:42.83 ID:1Kzq/YqA.net] >>159 mainまで戻る必要はない 通常は必要なところでエラー処理をする >>160 エラー処理するところまでの途中のみでResult通過 だから手間なんてない 165 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 20:23:54.74 ID:i/bC1p00.net] Rustに例外付けなかったの失敗だったな 166 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 20:27:14.41 ID:9ScRXeeN.net] 深い再入階層からジャンプして戻って来れる便利な例外 167 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 20:31:02.00 ID:Lj/9/9R5.net] >>165 デストラクタ内で例外を投げないのは成功 168 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 20:33:32.03 ID:uC26F0Aa.net] >>164 > 通常は必要なところでエラー処理をする それは回復可能なエラーの話だろ > エラー処理するところまでの途中のみでResult通過 > だから手間なんてない 169 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 20:50:07.22 ID:1Kzq/YqA.net] >>168 まともなプログラムならば回復可能か否かに関係なく各々のエラー処理をきちんと行う そのエラー処理を最下位関数内の関数呼び出し毎に行うのではなく中位の関数である程度まとめて行う時にResult返しとそのスルーで集める このような下位のエラー処理をまとめて行うことはRustに限らずどのプログラミング言語でも同じ 170 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 20:50:28.09 ID:uC26F0Aa.net] >>164 途中で送信してしまった > エラー処理するところまでの途中のみでResult通過 途中？ main まで帰る話はもういいのか？w 171 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 20:51:44.09 ID:uC26F0Aa.net] >>169 回復不可能なのにどんなエラー処理するつもりなんだよw 172 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 20:58:27.94 ID:1Kzq/YqA.net] >>170 mainまで戻したいかどうかはそのプログラムの自由であってRustとは何ら関係がない これは例外のある言語でも同じ 例外catchする場所はそのプログラムの自由 173 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 21:06:59.40 ID:uC26F0Aa.net] 回復不可能とか言わなくなってて草 174 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 21:07:51.47 ID:dHwZCroo.net] 元々の回復不能な話はこれだけど >>47 >> ネットワーク前提にしてる時に、panicになるのはバグではないよ？ おもちゃなプログラムを除くとそういう状態は回復不能と扱わなくて 回復不能はまず滅多に起きることではないよね そのケースだとネットワークが使えないことを知らせて使えるようになるまでデータを維持して待つ panicで終わらせてよいのはかなり限定された場合だけとなるよね 175 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 21:19:29.68 ID:mdZRdLQP.net] 回復不能連呼してる人が具体的にどんな状況でのエラーを想定してるのか説明しないのに建設的な議論になるわけがないな 176 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 21:38:32.03 ID:jfU7NhFo.net] プログラムを使う側からしたら回復可能かどうかなんて些細な問題で処理できる or できないがすべて そもそも技術的に回復可能であってもそのような実装になっていないプログラムなんて腐るほどある 177 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 21:42:16.22 ID:1Kzq/YqA.net] >>173 既に書いたように回復可能か否かに関係なくエラー処理は行われる そして上位でまとまった共通なエラー処理をする時に 途中関数での?オペレータ付加とResult返しのみでRustでは実現できる 例外機構という複雑で非効率な仕組みは必要ないという話が本題 178 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 22:02:40.15 ID:jfU7NhFo.net] >>174 >そのケースだとネットワークが使えないことを知らせて使えるようになるまでデータを維持して待つ それは対話式のUIを持っているアプリ限定。CLIのアプリならエラーメッセージを出力して終了するのが一般的 179 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 22:10:02.38 ID:1Kzq/YqA.net] >>178 その場合でもライブラリの奥底からResult返しの連鎖があり エラーメッセージを出力する上位まで来てからそのResult処理をする形に変わりなし 個別プログラムの方針とは関係ない共通の話がなされている 180 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 22:13:28.38 ID:IhW3z+yo.net] コマンドラインオプションでリトライ指定機能追加するときに なんでもかんでもpanicだと泣きを見るぞ 181 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 22:19:43.76 ID:uC26F0Aa.net] 回復不能って言ってるのにリトライ機能追加とかw 182 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 22:21:01.07 ID:uC26F0Aa.net] >>177 だから実現はできるけど面倒だって話 183 名前：デフォルトの名無しさん [2023/01/30(月) 22:26:05.18 ID:N/PzAAZV.net] fs::read_to_stringでエラーが返されたら回復不能なんでしょw 184 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 22:38:54.58 ID:IhW3z+yo.net] >>181 接続失敗するだけでpanicにしてるらしいからな 185 名前：デフォルトの名無しさん [2023/01/30(月) 22:40:43.76 ID:xNQxd4Kt.net] >>178 curlとかリトライできたりするCLI使ったことないの？ 元の質問者が>>39でGUIへの対応方法がわからないと言ってるのも本質的なエラー処理を理解せずpanicしてるからだぞ 186 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 22:43:08.31 ID:jfU7NhFo.net] >$ cat foo.txt >cat: foo.txt: そのようなファイルやディレクトリはありません ここで正しいファイル名を入力しろなどと言いだすCLIアプリは相当レア 187 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 22:48:41.78 ID:mdZRdLQP.net] >>186 その状況でエラー出して終了させるのは良いとして、まさかpanicさせるなんて言わないよね？ 188 名前：デフォルトの名無しさん [2023/01/30(月) 22:49:07.10 ID:Rt4q8oMT.net] >>186 $ cat foo.txt bar.txt とでもやってみろよ 189 名前：デフォルトの名無しさん [2023/01/30(月) 22:53:39.09 ID:xlgBAXsb.net] 「回復不能」って言葉がよくないんだろうな エラーの種別についてある程度の前提知識を持ってないとなんでも恣意的に回復不能に分類しちゃう 190 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 22:59:07.16 ID:nWXKDIRj.net] 通りすがりのF#erですが、RustでもRailway指向ってオススメですか？ 191 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 23:25:38.10 ID:nWXKDIRj.net] F#の記事ですが、ResultかpanicするべきかをRailway指向を考えた方が記事にしてます。 https://fsharpforfunandprofit.com/posts/against-railway-oriented-programming/ ドメインエラーはResult、それ以外はpanicの方が良いって言ってるぽいかな。 192 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 23:30:11.69 ID:dHwZCroo.net] >>183 その場合でも例えばこのように Result処理せずにunwrap()してpanicさせたら困ることをpanic派が気付いているかどうかだよね fn foo(path: impl AsRef<Path>) -> String { 　let text = fs::read_to_string(path).unwrap(); 　// テキスト処理略 } 193 名前：デフォルトの名無しさん [2023/01/30(月) 23:56:32.97 ID:WvBRUZ9a.net] >>191 それは例外を使うべきケースと戻り値でエラーの種類を表現すべきケースの区別を例外機構のある言語を前提に語ってるもの エラーの種別についての前提知識としては役立つがRustのResultとpanicの区別とはまた違う その人が3種類に分類したエラーのうちPanicsだけがRustで言うところのpanicを使うケースにあたる 194 名前：デフォルトの名無しさん mailto:sage [2023/01/30(月) 23:59:11.83 ID:dHwZCroo.net] >>191 その文書のResultやpanicはもちろんRustのそれらとは意味が異なるよ そして代わりに例外でエラーを返すと書かれていてもRustには例外は無いわけでｗ 195 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 00:14:04.93 ID:c7ed+PvI.net] 複おじ死んだんじゃなかったの？ いい加減コテつけてくれよな あと新年の挨拶もまだだろ？まだ1月のうちにやっとけ 196 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 01:21:48.37 ID:CDUXqGTR.net] >>194 >>193 Rustは例外が無い>try-catchやthrowが無い。 という理解で有ってます？ となると、Resultの守備範囲が広くなりそうですね。 197 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 04:50:14.13 ID:JnYo5yDi.net] panic・回復不能エラーは滅多にない。 Ruby on Rails でも滅多にない ファイルが存在しない、数値に変換できないなど、予測可能なエラーは例外。 こういうのは普通に起きるエラー たぶん、panicを使う香具師は、書き捨てのコードだろ。 リソースの解放・後始末が面倒くさいから 198 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 06:55:08.97 ID:YNMDboNb.net] >>191 これに尽きるでしょ ・Panics. These are errors that leave the system in an unknown state, such as unhandleable system errors (e.g. “out of memory”) or errors caused by programmer oversight (e.g. “divide by zero,” “null reference”). 要はpanicはプログラマーにはどうしようもないメモリー不足とかプログラマーの想定外の状態になったときに使うものだよ 他のプログラム言語でもAssertとか使うだろ 199 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 07:40:09.15 ID:7I30yv0f.net] >>196 そう Rustはtry throw catchの例外機構を意図的に排除している 例外機構の導入は複雑になるだけだなく効率面での不利や他の機能との相性など様々な問題がある そのためRustやGoなどのプログラミング言語では例外機構が導入されていない 例外機構のある言語の多くでは例外が素通りする途中の関数でその宣言をしないためコードを見てもその有無が分からない問題もあった Rustでは戻り型のResultによりそれを扱うことの有無が明確になっている さらに"?"オペレーターによりResult値が下から上へ素通りすることも明確になっている つまり簡素化と効率化と可読性の向上全ての両立をRustは実現している 200 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 07:49:11.46 ID:YNMDboNb.net] >>199 > 例外機構のある言語の多くでは例外が素通りする途中の関数でその宣言をしないためコードを見てもその有無が分からない問題もあった そりゃ途中の関数にはその例外は関係ないからね 関係ないものを見る必要はない

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef