Rust part19

**デフォルトの名無しさん** · 2023/01/17(火) 12:41:32.25

公式
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/

**はちみつ餃子** ◆8X2XSCHEME · 2023/01/28(土) 02:45:04.16

>>82
Rust の文化にあまり詳しいわけじゃないけど panic を呼び出すのって C/C++ で言うところの assert 的なもんでしょ。
普通に考えたら panic が呼ばれるのはモジュールの仕様に対して使い方が間違っているかリカバリ不可能な場合。
逆に言えば使い方が正しくてリカバリ可能な状況で panic になるべきではない。

モジュールの使い方が完璧に正しいプログラムを書いても panic が引き起こされてしまうなら panic の使い方のほうが間違ってる。
絶対に通信が確立する状況で使えという仕様を設定すりゃあ間違ってるのは使い方のほうではあるけどさー、
ネットワークでそれは不可能な前提じゃん？ありえない前提を元にするのは不毛だろ。

**デフォルトの名無しさん** · 2023/01/28(土) 07:46:19.92

>>82
> 仕様上、エラーハンドリングを行わなければならないとされていないならバグではないでしょ....
仕様バグ...

**デフォルトの名無しさん** · 2023/01/28(土) 09:58:07.00

ユーザーにとって不自然な動作をすれば開発者が仕様だと言い張ったところでそれはバグだよ

**デフォルトの名無しさん** · 2023/01/28(土) 10:54:36.16

エラーにも回復可能なエラーと不可能なエラーがあり、panicすると回復不可能な状態になるんだから、回復可能なエラーはpanicすべきじゃない。ましてや通常使用でしばしば発生する状態でpanicするのは言語道断だわな。

**デフォルトの名無しさん** · 2023/01/28(土) 10:57:15.78

assertというかexitやな。推奨はされん、普通はデバッグで面倒な時くらいじゃないか。

**デフォルトの名無しさん** · 2023/01/28(土) 11:52:23.17

>>86
MSの開発者を説得してくれ

**デフォルトの名無しさん** · 2023/01/28(土) 11:54:06.56

>>88
exitは正常終了でも呼ばれるからassertのほうが意味的には近いと思うぞ

**デフォルトの名無しさん** · 2023/01/28(土) 14:06:35.25

マルチスレッド界隈ではスレッドの一つや二つ終了しても
回復不可能と思ってないでしょ

**デフォルトの名無しさん** · 2023/01/28(土) 14:59:51.08

The Bookにある回復不可能かどうかという判断基準は曖昧であまり役に立たない

Resultを伝播させてトップレベルでログ出力でもしてabortさせるのに比べて
問題発生箇所でpanicさせるメリットは処理をinfallibleな関数として定義出来ること

逆に言えばバグでも無いのにinfallibleな関数呼び出しでpanicで落ちるような設計はそれ自体がバグの可能性大

**デフォルトの名無しさん** · 2023/01/28(土) 17:20:49.61

0か1かではなくバグが何個あるのかも重要
落とせば一つ？
進めれば二つ以上？

**デフォルトの名無しさん** · 2023/01/28(土) 17:59:00.91

>>93
イミフ

**デフォルトの名無しさん** · 2023/01/28(土) 19:43:12.93

>>86
開発者なんていないよ、みんなユーザーだよって言い張ったのがオープンソースだね

**デフォルトの名無しさん** · 2023/01/28(土) 21:12:57.88

>>95
イミフその3

**デフォルトの名無しさん** · 2023/01/28(土) 22:16:55.89

ユーザーと開発者を分断して対立煽るのをやめようってことだよ

**デフォルトの名無しさん** · 2023/01/28(土) 23:41:24.90

自分(たち)で用いるツール類だけは
自明な前提を満たしていない場合に限り
エラー処理をサボったpanicで終わらせてもよい

それ以外のpanicは状態矛盾など続行不可禁止で発生するが
正しくエラー終了させるべきものであり
panic発生はバグと呼んでも差し支えない

**デフォルトの名無しさん** · 2023/01/29(日) 01:28:33.47

>>98
panicをハンドリングしないのはバグかどうかは仕様次第と完全に認めてるのに、建設的な議論って・・・
作法的な話や、ユーザーフレンドリなUIでエラーメッセージを出したい、いきなり終了して欲しくないのであってもプロジェクトごとに異なるし、一般的な普遍性なんて「仕様上」に何が言いようがあるんだ？
オレはいつもこうしてます！という癖だったらいくらでも言えるし、100人集めてアプリケーションのレイヤーでpanicをハンドリングする/しないでアンケートしてどっちが人気かで正しさが決まるようなものではない。
最終的に「アプリケーションのレイヤーでパニック起こすのはバグの時だけ」とかいうのは明らかに間違ってるでしょ
そうするような特定のプロジェクトの仕様がたまたま（確率的に）一致するかもしれないが、それも一般化できる話ではないよ。

まあ、お望みの建設的な議論をするなら、アプリケーションをライブラリのように使用できる余地があるならResultsなどでErrorを返すのはとても良いですが、それでもpanicをハンドリングしてErrorで返すべきでは”無い”でしょうね
なぜならRustはそれを推奨していないし、Errorチェックしてをpanicに変換する方向性はあっても、panicをErrorに変える方向性は、仮にログ出力してもpanicの握り潰しやエラー情報の欠落に等しい。（なぜならログへのI/Oエラーになってる可能性もあるから）
それは、そもそもRustのpanicは言葉上は回復不能なエラーであり、バグではなくメモリーに物理的な障害が発生して配列インデックスが変になったとか、処理が続行できない、もしくはいったん特定の場所に戻って回復できないときに使われる思想。
なので、panic->Error変換処理が正常に働くかも怪しい。だからRustはそれを捉えず上位へ流して最低限やるスタックの巻き戻しのみ処理を推奨し、即座に終了させる（＝プログラムが落ちる）
Linusはこのスタックの自動巻き戻しがとても気に入らないらしいが、理由は巻き戻し処理が正常に働く理由が無いからだ。
それを無理やり捉えて、スタックトレースが出るのが嫌、即座に終了するのが嫌、は分かるけどpanicで終了したからと言って仕様に書いてなければバグじゃないでしょ

これを癖でやってしまうのはtry-catch構文があるC#やJava系から来た人が多いのではないかな...？

**デフォルトの名無しさん** · 2023/01/29(日) 02:35:07.62

誰もpanicをResultに変換する話はしとらんやろ

**デフォルトの名無しさん** · 2023/01/29(日) 07:18:58.36

て言うか>>99は前半と後半で矛盾してるしアホほど長文を証明してるw

**デフォルトの名無しさん** · 2023/01/29(日) 11:17:47.92

panicは仕様に書いてなければバグでしょ
どんなプログラム書いてんだよ

**デフォルトの名無しさん** · 2023/01/29(日) 11:27:06.90

エラーハンドリングという言葉をpanicをハンドリングしてResultにすることだと思ってたのか
そりゃ噛み合わないわな

**デフォルトの名無しさん** · 2023/01/29(日) 13:10:21.68

例えばpythonのexitの代用としてpanicを使ったところで何の問題もない

**デフォルトの名無しさん** · 2023/01/29(日) 14:45:33.86

問題ありまくり
同じexitがあるのにわざわざpanicで代用するメリットは何？

**デフォルトの名無しさん** · 2023/01/29(日) 15:29:55.13

まずは異常終了と正常終了を分断するメリットを知る必要がある

**デフォルトの名無しさん** · 2023/01/29(日) 15:33:47.16

>>105
へー今初めて知った
The BookのCommon Programming Conceptsあたりにそれっぽい記述はないし
中断したければpanicするしかないと思っていたよ
後学のためにどこで解説されているのか教えてほしいな

**デフォルトの名無しさん** · 2023/01/29(日) 15:48:49.58

panic!すべきかするまいか
https://doc.rust-jp.rs/book-ja/ch09-03-to-panic-or-not-to-panic.html

**デフォルトの名無しさん** · 2023/01/29(日) 17:07:54.00

>>107
The Bookの12章を復習して
https://doc.rust-lang.org/book/ch12-00-an-io-project.html

ただThe Bookは他言語から来た人が最初に読むチュートリアルとして用意されてるものなのでカバーされてない内容も多々あるし深い解説がされてるわけでもない点は理解しておいた方がいいよ

**はちみつ餃子** ◆8X2XSCHEME · 2023/01/29(日) 17:16:49.84

標準ライブラリのマニュアルでも panic! はバグを説明するために使うということは書いてあるね。
https://doc.rust-lang.org/std/macro.panic.html

**デフォルトの名無しさん** · 2023/01/29(日) 18:20:40.83

>>107
exitはプロセスの終了状態コードを伝えることを兼ねたOSシステムコールだから通常の言語には必ずある
そしてそのことを分かっていればRust初心者であってもstd::process::exitをすぐに見つけられる

**デフォルトの名無しさん** · 2023/01/29(日) 18:41:07.89

>>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
・無条件でプロセスを終了させる
・実行スレッドも他のスレッドも一切スタック巻き戻しが行われない
→デストラクタ呼ばれない

**デフォルトの名無しさん** · 2023/01/29(日) 18:45:14.86

_exit()はシステムコールだけどexit()はライブラリの関数
pythonのexit()やsys.exit()は基本的にexitcodeを設定してSystemExit例外を投げてるだけ
os._exit()がprocess::exit()に近い

**デフォルトの名無しさん** · 2023/01/29(日) 18:46:31.90

>>112
例外のある言語と同じ感覚でプログラミングするのが一番の問題
それ抜きにpythonと比べとも意味ないよ

**デフォルトの名無しさん** · 2023/01/29(日) 18:48:13.88

一般的な他の言語におけるtry-throw-catchの機能が欲しいならば
それはRustやGoなどでは意図的に排除されていて存在しない
RustではResultで返すだけでよく利便性と効率を両立させている

**デフォルトの名無しさん** · 2023/01/29(日) 19:53:25.69

>>109
そこは見ているけど制御機構を説明しているところで同時に解説すべきなのでは

>The Bookは他言語から来た人が最初に読むチュートリアルとして用意されてるもの
なおさら他言語でメジャーな機能や実装と対比した解説が必要では

>>112
unwind不可なのは使いにくい場面が少なからずありそう
今作っているのはdrop使っているから強制abortは問題しかない

**デフォルトの名無しさん** · 2023/01/29(日) 21:27:11.45

RustのdropにはRcという具体的な目的がある
Rcが完璧主義ではないのでdropも完璧にする必要を感じない

**デフォルトの名無しさん** · 2023/01/29(日) 21:32:58.27

>>112
>Pythonのsys.exitと同じ感覚でstd::process::exit使うほうがはるかに問題では？

RustではResultをmainまで戻してからprocess::exitする
Pythonは例外という仕組みでランタイムがそれをやってくれる
panicはやってることがにてるからという理由で使うようなものじゃない

**デフォルトの名無しさん** · 2023/01/29(日) 21:46:05.85

>>115
そうではないよ？例えばrustの標準ライブラリのTcpStreamにはset_read_timeoutでタイムアウトを設定すると、それ設定値以上でpanicを起こす。
これは通信中に非同期制御やスレッド監視などをしないための苦肉の策でResultをmatchするだけという考えから外れて、回復不能としているのだがリードタイムアウトであろうと再試行するようなプログラムではpanicを考慮しなければならない。
一方でTcpStreamの多くはResult<>を返すので、高度なプロトコルを作るような場合、受け取ったデータなどを調べてpanicさせる方法などが公式ドキュメントにも述べられている。

**デフォルトの名無しさん** · 2023/01/29(日) 21:46:28.34

The Bookに書いてるようにpanicを使う対象となるような回復不可能なエラーは常にバグによるもの

Rust groups errors into two major categories: recoverable and unrecoverable errors.
Unrecoverable errors are always symptoms of bugs.

**デフォルトの名無しさん** · 2023/01/29(日) 21:56:31.01

>TcpStreamにはset_read_timeoutでタイムアウトを設定すると、それ設定値以上でpanicを起こす。
readで設定したtimeout値を超えたらpanicすると言ってる？
少なくともリファレンスにはResultが返されるとあるんだが

**デフォルトの名無しさん** · 2023/01/29(日) 21:57:37.90

>>113
_exitはexit_groupのラップ関数だよ

**デフォルトの名無しさん** · 2023/01/29(日) 22:09:10.65

言語の理想と実装は違うから食い違いが出ている。現実的には作者がめんどくさくなったり、ライブラリとそれを利用するレイヤーの区別があいまいな場合などに大域脱出とスタック巻き戻しがしたいだけで回復可能な場合にもpanicを投げてしまう実装もありうるのでバグではない。標準ライブラリでさえそうなのだから

**デフォルトの名無しさん** · 2023/01/29(日) 22:14:20.10

> 受け取ったデータなどを調べてpanicさせる方法などが公式ドキュメントにも述べられている。
これはpanicを使えということじゃなくサンプルコードとしての簡潔さ優先してるだけ
改善はされてきてるけどunwrapがあちこちにあるのと同じ
箸の上げ下げレベルで手取り足取り教えてもらうことを期待し過ぎじゃないか

**デフォルトの名無しさん** · 2023/01/29(日) 22:21:53.21

>>118
うん別に良いデザインではないよ、そこは同意する
俺は「同じexitがあるのに」という表現が招きかねない誤解に釘を差しただけです

**デフォルトの名無しさん** · 2023/01/29(日) 22:33:36.00

>>124
もちろんドキュメントで述べられてる通り、Resultが一番の選択肢で回復可能で返せるのにpanicを使うのは愚策でしょう。だから理想はとそういってますよね？
手取り足取り教えてもらうのはどちらなのかというよりも、どうしてもpanicで終了はバグだという理想・意見をとゴリ押ししたいだけに見えます。
これは（＝回復可能なのに）panicを使えということじゃなくというのは強く同意ですが、そうなっていないものを使用している現実があるという話でpanicを書いてないことに期待し過ぎじゃないか？ということになります

**デフォルトの名無しさん** · 2023/01/29(日) 22:38:36.38

>>119
Rustでそのような形のpanicの使われ方はしませんしpanicは起きません
タイムアウトもio::Resultでio::Errorが返るだけです

これはC言語で書いてSO_RCVTIMEOでタイムアウト値を設定してreadで-1とerrnoが返る時と全く同じ状況です
言語独自の例外機構を持つ言語は複雑にしてややこしくしているだけなのでその考えをまず捨てるところからスタートしましょう

**デフォルトの名無しさん** · 2023/01/29(日) 22:44:10.80

>>126
今回のケースでも標準ライブラリはpanicを起こしていませんしpanicを起こす仕様はありません
もしpanicが起きたのならばそれはあなたがResultの処理をせずに強引にunwrap()したためであり
あなたのコードがpanicを引き起こしたのです

**デフォルトの名無しさん** · 2023/01/29(日) 22:49:39.52

The BookにmainまでResultで戻す実践的な設計方法って解説されてる？
機能の説明はあっても実装するうえでどのようにしたらいいのかってところは抜けているような
ググるとstd::num::*を返す例、Stringを返す例、enumを返す例などが出てくるが
どのように使い分ければいいのかって点は不明
このスレ見ていてもこの部分に関する資料を提示している人は見かけないし

>>124
>箸の上げ下げレベルで手取り足取り教えてもらうことを期待し過ぎじゃないか
箸文化圏なら要らないだろうがスプーン・フォーク文化圏なら要るんじゃね
他所と大きく違うのであれば十分な説明を求められるのは当然では

**デフォルトの名無しさん** · 2023/01/29(日) 22:51:25.05

> 例には、不正なデータを渡されたパーサとか、訪問制限に引っかかったことを示唆するステータスを返す
> HTTPリクエストなどが挙げられます。このような場合には、呼び出し側が問題の処理方法を決定できる
> ようにResultを返してこの悪い状態を委譲して、失敗が予想される可能性であることを示唆するべきです。
> panic!を呼び出すことは、これらのケースでは最善策ではないでしょう。

**デフォルトの名無しさん** · 2023/01/29(日) 23:19:15.93

>>129
mainまでResultで戻すにはResult型を返す関数を書くだけ
何も難しいことはなく複雑なこともなくシンプル
Resultは単なる型の一つでOk値とErr値のEnumに過ぎない
Rust言語はResultに対し例外機構のような特別扱いをしていない
ResultはTryをimplしてるから『？』オペレータを適用できるなどくらいしか他の型との違いはない
したがって新たに勉強すべき点はそこだけだが『？』は使わずとも同じことを記述することができる

**デフォルトの名無しさん** · 2023/01/29(日) 23:31:48.93

>>131
Result<T, E>のEってなしに出来たっけ？自分が言いたいのはそういう話なんだけど

**デフォルトの名無しさん** · 2023/01/29(日) 23:45:24.52

>>132
特別扱いはないので自由
例えばbool相当としてResult<(),()>型を使ってももちろん機能する
またOption<T>相当としてResult<T,()>型
通常はそれぞれ前者を使って必要なところで初めてResultへ変換が普通

**デフォルトの名無しさん** · 2023/01/29(日) 23:50:28.46

>>129
> The BookにmainまでResultで戻す実践的な設計方法って解説されてる？
12章はどうだろうか、minigrep を作るところ

**デフォルトの名無しさん** · 2023/01/29(日) 23:59:14.71

>>129
12章に書いてるでしょ

それに一連のレスで書いてる設計指針はRust特有の話じゃないよ
アプリのトップレベルに集約エラーハンドラを用意するのは例外機構のある他の言語でも同じだし
エラー発生時にexitcodeを設定してプロセス終了させるのはUIに相当するレイヤーの仕事だからそこまで戻してハンドリングするのも他の言語でも同じ
pythonだとしてもいろんなレイヤーでsys.exitするのは典型的なダメなやり方

**デフォルトの名無しさん** · 2023/01/29(日) 23:59:23.38

RustはResultを特別視しない
例えばGoのようにRustで(正常値, エラー値)とタプルで返す関数群でプログラミングしても同様に動く
じゃあなぜResultを用いるのか？
・統一した型があった方がいい
・二値ではなく二種のEnumでよい
・便利なメソッド群を標準で用意できる
・標準ライブラリをResultで統一できる

**デフォルトの名無しさん** · 2023/01/30(月) 00:00:50.47

すまん被ってた

**デフォルトの名無しさん** · 2023/01/30(月) 00:02:36.60

>>132
なんでEを無くしたいの？

**デフォルトの名無しさん** · 2023/01/30(月) 00:09:50.85

Rust特有のエラーハンドリングの実践的な知識はanyhow/thiserrorの使い方を学ぶといい
それらのcrateを使わず自前でやるとしても何を用意する必要があるのかわかる

**デフォルトの名無しさん** · 2023/01/30(月) 00:14:09.92

副作用がない関数なら大域脱出を使うべきでないのは分かる
副作用に寛容で大域脱出に不寛容なのは分からん

**デフォルトの名無しさん** · 2023/01/30(月) 00:19:52.36

>>139
それは初心者には混乱の元
panicとか言ってる初心者たちが最初にすべきことは一つ
「unwrap()を使わずにプログラムを書く」

**デフォルトの名無しさん** · 2023/01/30(月) 08:11:22.12

>>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でも構わないとも取れる

**デフォルトの名無しさん** · 2023/01/30(月) 08:21:18.23

もういいよ。お前はずっとpanic使っとけ。

**デフォルトの名無しさん** · 2023/01/30(月) 08:28:01.11

Rustをきちんと学ぶ気があるならば
まずはpanicもunwrapも使わずにプログラムを自在に書けるようになること
そういう基礎ができていないから勘違いしてpanicにこだわろうとしてしまう

**デフォルトの名無しさん** · 2023/01/30(月) 08:31:46.93

評判の悪いthe book 日本語版にすら使い分けの記述あるのに、それを無視して回復不能なエラー処理以外でpanicを推奨しようとするのは何なのかね。

エラー処理
Rustには例外が存在しません。代わりに、回復可能なエラーにはResult<T, E>値があり、プログラムが回復不能なエラーに遭遇した時には、実行を中止するpanic!マクロがあります。

**デフォルトの名無しさん** · 2023/01/30(月) 08:40:51.18

the bookを一通りきちんと読んだならunwrapは極力使うべきではないものだと理解できるはずなんだけどな

**デフォルトの名無しさん** · 2023/01/30(月) 11:00:50.02

>>138
panicで大域脱出して構わない状況ならmainで必要な情報はreturnするか否かだけ
これはResultが保持しているのでEは不要

**デフォルトの名無しさん** · 2023/01/30(月) 11:23:44.77

>>147
すまんけど全然わからない
TとEの両方がないとResultが存在できないと思うんだが

**デフォルトの名無しさん** · 2023/01/30(月) 11:26:30.09

TとEを()にしたら実質ないなので

**デフォルトの名無しさん** · 2023/01/30(月) 11:36:33.64

>>142
ちゃんと読もう
そして全体の文脈を理解しよう
https://doc.rust-lang.org/book/ch12-03-improving-error-handling-and-modularity.html#fixing-the-error-handling

**デフォルトの名無しさん** · 2023/01/30(月) 11:50:16.61

>>149
Eをunit typeにすることをEをなしにすると言ってることは理解したが
>panicで大域脱出して構わない状況ならmainで必要な情報はreturnするか否かだけ
これは全然わからない

大域脱出したいからpanic使いたがってるという動機部分は理解した

**デフォルトの名無しさん** · 2023/01/30(月) 12:08:29.21

exitcodeをちゃんと実装したい時は
process::exitのリファレンスに書いてるように
mainの戻り値にTerminationを実装した型を指定してprocess::exitは使わずmainから戻り値を返す方法が今は推奨

**デフォルトの名無しさん** · 2023/01/30(月) 12:56:41.01

>>151
処理継続不能なら終了するしかないからね。panicで終了しようが、mainまで戻ってからreturnしようが大差ない

**デフォルトの名無しさん** · 2023/01/30(月) 19:01:04.95

>>153
いやいや、深いところから脱出するのにResultだと途中の階層すべてで返さないとダメだからコーディングの手間が全然違うだろ

**デフォルトの名無しさん** · 2023/01/30(月) 19:07:00.52

>>154
でもアンチpanic君？はその手間を正当化したいっぽいじゃん

**デフォルトの名無しさん** · 2023/01/30(月) 19:15:25.77

日曜プログラマーの作るソフトときちんと作るソフトで基準がズレてる感じ

**デフォルトの名無しさん** · 2023/01/30(月) 19:23:44.43

そうやってすぐ人格の問題にする

**デフォルトの名無しさん** · 2023/01/30(月) 19:39:30.35

>>154
実際にコーティングしてみれば手間はほぼないと分かる
・返り値型をResult<>で括る
・ライブラリも自作もResult返す関数を上位へスルーするなら「?」を後置
たったこれだけの話
もちろんその場で処理したいResultや情報を増やしたいResultは今回の話以前に元々処理しているはず

回復不能なエラーなんて滅多に起きず
ほとんどはその場か上位関数で何らかの対応処理するエラーなのだから
panicは滅多に必要としない

**デフォルトの名無しさん** · 2023/01/30(月) 19:54:44.86

mainまで戻るってことはmain肥大化と同義。積極的にmainを複雑化させるべきいう主張か
もちろんプログラミングの定石的には1関数にあれもこれも詰め込むのは悪手だよな
panicダメ言っている人は実用的なプログラムを書いたことがあるのだろうか

**デフォルトの名無しさん** · 2023/01/30(月) 19:54:52.38

>>158
> たったこれだけの話
それを途中の階層全てでやらんとダメだろ
お前こそでかいプログラム組んだことないんじゃね？
そもそも途中の階層は自分が組んでるとは限らんし

**デフォルトの名無しさん** · 2023/01/30(月) 20:06:49.02

デストラクタ内でexitを使ってはいけない
デストラクタ内で利用可能な関数の中でexitを使ってはいけない
すべての関数はexitを使ってはいけない

こういうことかな

**デフォルトの名無しさん** · 2023/01/30(月) 20:18:26.31

なんかめっちゃ盛り上がってて草

**デフォルトの名無しさん** · 2023/01/30(月) 20:21:20.63

そもそもPythonのsys.exitだって本当は100点満点の正解コードを目指すなら独自例外作れって話だし
その程度の雑さでいいならRustでも雑にpanicしたっていいじゃない
教科書的な話じゃなく、もっと実利的な問題が何かあるなら教えてくれよ

**デフォルトの名無しさん** · 2023/01/30(月) 20:22:42.83

>>159
mainまで戻る必要はない
通常は必要なところでエラー処理をする

>>160
エラー処理するところまでの途中のみでResult通過
だから手間なんてない

**デフォルトの名無しさん** · 2023/01/30(月) 20:23:54.74

Rustに例外付けなかったの失敗だったな

**デフォルトの名無しさん** · 2023/01/30(月) 20:27:14.41

深い再入階層からジャンプして戻って来れる便利な例外

**デフォルトの名無しさん** · 2023/01/30(月) 20:31:02.00

>>165
デストラクタ内で例外を投げないのは成功

**デフォルトの名無しさん** · 2023/01/30(月) 20:33:32.03

>>164
> 通常は必要なところでエラー処理をする
それは回復可能なエラーの話だろ

> エラー処理するところまでの途中のみでResult通過
> だから手間なんてない

**デフォルトの名無しさん** · 2023/01/30(月) 20:50:07.22

>>168
まともなプログラムならば回復可能か否かに関係なく各々のエラー処理をきちんと行う
そのエラー処理を最下位関数内の関数呼び出し毎に行うのではなく中位の関数である程度まとめて行う時にResult返しとそのスルーで集める
このような下位のエラー処理をまとめて行うことはRustに限らずどのプログラミング言語でも同じ

**デフォルトの名無しさん** · 2023/01/30(月) 20:50:28.09

>>164
途中で送信してしまった

> エラー処理するところまでの途中のみでResult通過
途中？
main まで帰る話はもういいのか？w

**デフォルトの名無しさん** · 2023/01/30(月) 20:51:44.09

>>169
回復不可能なのにどんなエラー処理するつもりなんだよw

**デフォルトの名無しさん** · 2023/01/30(月) 20:58:27.94

>>170
mainまで戻したいかどうかはそのプログラムの自由であってRustとは何ら関係がない
これは例外のある言語でも同じ
例外catchする場所はそのプログラムの自由

**デフォルトの名無しさん** · 2023/01/30(月) 21:06:59.40

回復不可能とか言わなくなってて草

**デフォルトの名無しさん** · 2023/01/30(月) 21:07:51.47

元々の回復不能な話はこれだけど

>>47
>> ネットワーク前提にしてる時に、panicになるのはバグではないよ？

おもちゃなプログラムを除くとそういう状態は回復不能と扱わなくて
回復不能はまず滅多に起きることではないよね
そのケースだとネットワークが使えないことを知らせて使えるようになるまでデータを維持して待つ
panicで終わらせてよいのはかなり限定された場合だけとなるよね

**デフォルトの名無しさん** · 2023/01/30(月) 21:19:29.68

回復不能連呼してる人が具体的にどんな状況でのエラーを想定してるのか説明しないのに建設的な議論になるわけがないな

**デフォルトの名無しさん** · 2023/01/30(月) 21:38:32.03

プログラムを使う側からしたら回復可能かどうかなんて些細な問題で処理できる or できないがすべて
そもそも技術的に回復可能であってもそのような実装になっていないプログラムなんて腐るほどある

**デフォルトの名無しさん** · 2023/01/30(月) 21:42:16.22

>>173
既に書いたように回復可能か否かに関係なくエラー処理は行われる
そして上位でまとまった共通なエラー処理をする時に
途中関数での?オペレータ付加とResult返しのみでRustでは実現できる
例外機構という複雑で非効率な仕組みは必要ないという話が本題

**デフォルトの名無しさん** · 2023/01/30(月) 22:02:40.15

>>174
>そのケースだとネットワークが使えないことを知らせて使えるようになるまでデータを維持して待つ
それは対話式のUIを持っているアプリ限定。CLIのアプリならエラーメッセージを出力して終了するのが一般的

**デフォルトの名無しさん** · 2023/01/30(月) 22:10:02.38

>>178
その場合でもライブラリの奥底からResult返しの連鎖があり
エラーメッセージを出力する上位まで来てからそのResult処理をする形に変わりなし
個別プログラムの方針とは関係ない共通の話がなされている

**デフォルトの名無しさん** · 2023/01/30(月) 22:13:28.38

コマンドラインオプションでリトライ指定機能追加するときに
なんでもかんでもpanicだと泣きを見るぞ

**デフォルトの名無しさん** · 2023/01/30(月) 22:19:43.76

回復不能って言ってるのにリトライ機能追加とかw

**デフォルトの名無しさん** · 2023/01/30(月) 22:21:01.07

>>177
だから実現はできるけど面倒だって話

**デフォルトの名無しさん** · 2023/01/30(月) 22:26:05.18

fs::read_to_stringでエラーが返されたら回復不能なんでしょw