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/

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

>>178
curlとかリトライできたりするCLI使ったことないの？
元の質問者が>>39でGUIへの対応方法がわからないと言ってるのも本質的なエラー処理を理解せずpanicしてるからだぞ

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

>$ cat foo.txt
>cat: foo.txt: そのようなファイルやディレクトリはありません
ここで正しいファイル名を入力しろなどと言いだすCLIアプリは相当レア

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

>>186
その状況でエラー出して終了させるのは良いとして、まさかpanicさせるなんて言わないよね？

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

>>186
$ cat foo.txt bar.txt
とでもやってみろよ

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

「回復不能」って言葉がよくないんだろうな
エラーの種別についてある程度の前提知識を持ってないとなんでも恣意的に回復不能に分類しちゃう

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

通りすがりのF#erですが、RustでもRailway指向ってオススメですか？

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

F#の記事ですが、ResultかpanicするべきかをRailway指向を考えた方が記事にしてます。
https://fsharpforfunandprofit.com/posts/against-railway-oriented-programming/

ドメインエラーはResult、それ以外はpanicの方が良いって言ってるぽいかな。

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

>>183
その場合でも例えばこのように
Result処理せずにunwrap()してpanicさせたら困ることをpanic派が気付いているかどうかだよね

fn foo(path: impl AsRef<Path>) -> String {
　let text = fs::read_to_string(path).unwrap();
　// テキスト処理略
}

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

>>191
それは例外を使うべきケースと戻り値でエラーの種類を表現すべきケースの区別を例外機構のある言語を前提に語ってるもの
エラーの種別についての前提知識としては役立つがRustのResultとpanicの区別とはまた違う

その人が3種類に分類したエラーのうちPanicsだけがRustで言うところのpanicを使うケースにあたる

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

>>191
その文書のResultやpanicはもちろんRustのそれらとは意味が異なるよ
そして代わりに例外でエラーを返すと書かれていてもRustには例外は無いわけでｗ

**デフォルトの名無しさん** · 2023/01/31(火) 00:14:04.93

複おじ死んだんじゃなかったの？
いい加減コテつけてくれよな
あと新年の挨拶もまだだろ？まだ1月のうちにやっとけ

**デフォルトの名無しさん** · 2023/01/31(火) 01:21:48.37

>>194
>>193
Rustは例外が無い>try-catchやthrowが無い。
という理解で有ってます？

となると、Resultの守備範囲が広くなりそうですね。

**デフォルトの名無しさん** · 2023/01/31(火) 04:50:14.13

panic・回復不能エラーは滅多にない。
Ruby on Rails でも滅多にない

ファイルが存在しない、数値に変換できないなど、予測可能なエラーは例外。
こういうのは普通に起きるエラー

たぶん、panicを使う香具師は、書き捨てのコードだろ。
リソースの解放・後始末が面倒くさいから

**デフォルトの名無しさん** · 2023/01/31(火) 06:55:08.97

>>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とか使うだろ

**デフォルトの名無しさん** · 2023/01/31(火) 07:40:09.15

>>196
そう
Rustはtry throw catchの例外機構を意図的に排除している
例外機構の導入は複雑になるだけだなく効率面での不利や他の機能との相性など様々な問題がある
そのためRustやGoなどのプログラミング言語では例外機構が導入されていない

例外機構のある言語の多くでは例外が素通りする途中の関数でその宣言をしないためコードを見てもその有無が分からない問題もあった
Rustでは戻り型のResultによりそれを扱うことの有無が明確になっている
さらに"?"オペレーターによりResult値が下から上へ素通りすることも明確になっている

つまり簡素化と効率化と可読性の向上全ての両立をRustは実現している

**デフォルトの名無しさん** · 2023/01/31(火) 07:49:11.46

>>199
> 例外機構のある言語の多くでは例外が素通りする途中の関数でその宣言をしないためコードを見てもその有無が分からない問題もあった
そりゃ途中の関数にはその例外は関係ないからね
関係ないものを見る必要はない

**デフォルトの名無しさん** · 2023/01/31(火) 07:53:28.80

>>200
コードレビューやリファクタリングや移植作業をしたことがあればそれがコードに見えないことは非常に困ると分かる
Rustはそれがはっきりと分かるため可読性が良い

**デフォルトの名無しさん** · 2023/01/31(火) 07:59:50.04

mainからリターンするのであればプログラムの終了に至る条件が増えるほどmainの条件分岐がでかくなる
ってことも理解できない人がpanicダメとか言っているんだね

**デフォルトの名無しさん** · 2023/01/31(火) 08:27:46.22

このスレ見ていると、Rust勉強しているのにコールスタックとかスタックフレームを理解していないやつて意外と多いのが分かるな。

そもそもmainはスタックの根元で、OSとかプログラマーから見てプログラムそのものの代表だろ。
正常なフローならmainで始まってmainで終わるのは定石であって、正常なフローを破壊するpanicは異常事態。

Rustはスタックを重視してResultとか?演算子とか整備しているんだから、わざわざ用途外でpanicを使うのはRustのコンセプトを理解できていない証拠。そんなにスタックフレームのフロー制御が嫌ならRust以外を使ったら？

**デフォルトの名無しさん** · 2023/01/31(火) 08:35:12.13

>>202
そもそもpanicするのはメモリ不足くらいしかない
それも最近はtry_reserve()などpanicを避ける対応も増えてきたがまだpush_within_capacity()など安定化していないな
あと固定サイズ内でやりくりするArrayVecのtry_push()を使うこともよくある

**デフォルトの名無しさん** · 2023/01/31(火) 08:36:17.38

例外がないせいで、複数ライブラリ使うとエラー型を合成する必要があってつらいわ

**デフォルトの名無しさん** · 2023/01/31(火) 08:39:39.26

>>200
入れ子になった関数の途中かどうかなんて関係なく、自身が呼び出した関数から出る例外に無関係な状況など考えにくいんだが

**デフォルトの名無しさん** · 2023/01/31(火) 08:41:05.82

>>201
何が困るのか具体的に書いてみ

**デフォルトの名無しさん** · 2023/01/31(火) 08:42:54.02

>>206
自分が関与しない例外なんだろ？
その関数にできることなんてないはずだが？

**デフォルトの名無しさん** · 2023/01/31(火) 08:43:45.56

>>205
それは"?"オペレータのところでFrom::from(err)変換が自動適用されるので変換をimplしておけばよいだけ

**デフォルトの名無しさん** · 2023/01/31(火) 08:49:38.58

panic派の主張は「肥大化するとなんかダサいからエラー処理サボってpanicさせとくわ。コード量は減ってスッキリするから格好いいでしょ」という風にしか聞こえない
どれだけ肥大化しようとも想定が必要なエラー処理を省略しては駄目だろう

**デフォルトの名無しさん** · 2023/01/31(火) 08:49:41.53

>>207
例外がそこを通過するのか否かそこを見ただけで分からないからレビューでもリファクタリングでも何でも不便すぎる
一方でRustはそこがはっきりしていて可読性が良い
未処理な事項があって上位へ処理を委託していると明確に分かる

**デフォルトの名無しさん** · 2023/01/31(火) 08:51:55.45

>>205
とりあえず合成したいならanyhow使えばいい
勝手に全部合成されるから使い勝手は例外と変わらんと思うよ

**デフォルトの名無しさん** · 2023/01/31(火) 09:03:32.22

>>212
anyhowで勝手に合成されたエラー型への参照をmain()のifで場合分けしようとしたけど
JSのinstanceof 演算子的な処理のやり方が分からんかったわ

**デフォルトの名無しさん** · 2023/01/31(火) 09:09:12.08

>>211
だから不便すぎるとかふわふわした言葉で語るなよw
具体的に何が不便なんだよ

**デフォルトの名無しさん** · 2023/01/31(火) 09:12:07.56

>>210
panicはバグとかメモリー不足とかでどうしようない状態になったときに呼び出されるもので通常のエラー処理なんてできないってことぐらい理解しなよ

**デフォルトの名無しさん** · 2023/01/31(火) 09:18:10.08

>>213
そういう使い方をしたいならば例えばライブラリA,B,Cに対してMyErrorをEnumでErrorA,ErrorB,ErrorC各収容した方が扱いやすさも効率も良い
そのEnumに格納するだけのコードimpl From<MyError> for ErrorAしておくだけで簡単

**デフォルトの名無しさん** · 2023/01/31(火) 09:23:20.28

>>216
全部自動でやってよ

**デフォルトの名無しさん** · 2023/01/31(火) 09:28:45.86

>>214
Rustでは通過する途中の関数においても"?"オペレータの有無で未処理エラーを上位へ委託しているか否かが明白に分かる
だからコードレビューがしやすいし機能追加やリファクタリングする時にも見落としがない

一方で例外機構のある多くの言語では通過する途中の関数を見ても例外が通過するのか否かすら分からない
範囲を大きく広げて探し回らないといけなくなりムダな作業も発生して不便である

**デフォルトの名無しさん** · 2023/01/31(火) 10:14:19.93

>>205
自分のcrate用にエラーenumを定義して下位のエラーはそれにwrapするんだよ
その辺を楽させてくれるのがthiserror

カスタムな例外を定義しなくてもBulit-inの例外を使い回すだけで規模の小さいプログラムなら書ける例外+継承のある言語とは違うところ
Rustの場合はioエラーのみとかじゃなければ常にエラーenumを書くようになる

**デフォルトの名無しさん** · 2023/01/31(火) 10:15:37.08

>>218
だから自分が関与しない例外を調べて何をするんだ？
例外使うなら例外安全に作るのは当たり前でその関数が関与したリソースはその関数がきちんと始末することでなんの問題もないでしょ？

**デフォルトの名無しさん** · 2023/01/31(火) 10:18:35.43

>>217
そこは自由度があるから自分で必要性に応じて仕様を決めるべき
完全にサボりたいならanyhow等を使えばよいがその代わりにdynによる非効率さと分類の扱いにくさがトレードオフ

**デフォルトの名無しさん** · 2023/01/31(火) 10:29:38.37

>>220
中間関数は関与していないのではなくcatchしないことで例外エラーを上位へ移譲している
機能追加やリファクタリングではその処理位置が変わり得るから無関係ではなく把握する必要がある
同じことをRustならば上位への移譲があるか否かが明確に分かるため非常にやりやすい

**デフォルトの名無しさん** · 2023/01/31(火) 10:37:25.48

>>222
> 機能追加やリファクタリングではその処理位置が変わり得るから無関係ではなく把握する必要がある
そりゃその関数が関与するような修正するならな、当たり前
でも全ての関数が毎回関与するわけじゃないだろ
なんかダメな理由を必死に探してるとしか思えないけど

**デフォルトの名無しさん** · 2023/01/31(火) 10:41:06.15

>>223
コードレビューでも同じ
上位への移譲の有無がはっきり分かるRustは可読性が良い

**デフォルトの名無しさん** · 2023/01/31(火) 11:26:55.99

メモリ不足でパニックとか言っている時点で全く判かっていないの草
メモリのアロケーションに失敗した場合パニックしてもその動作は保証されない
なぜならスタックの巻き戻し中にメモリのアロケーションが試みられないことを保証するのは難しいからだ
そのアロケーションに失敗した場合に二重パニックになる
パニック時にアボートする場合は別だが、その場合はリソースやロックの開放もれが発生する可能性があるね

**デフォルトの名無しさん** · 2023/01/31(火) 11:52:51.31

>>225
全然ここの話を聞いてなかったけど、C++だとデストラクタは内部で例外を発生しては
ならないと決まっているから、デストラクタ内部ではメモリー不足例外も
発生させてはならない。

**デフォルトの名無しさん** · 2023/01/31(火) 11:55:03.20

>>226
[補足]
Java などでは、例外を投げるには throw new SomeException(); のようにするが、
C++ では、throw SomeException() のようにする。つまり、前者はヒープから、
後者はスタックから例外オブジェクトを確保する。なので、例外throwそれ自体は
メモリー不足にはならない。

**デフォルトの名無しさん** · 2023/01/31(火) 11:56:57.46

Resultでエラーを表現する一番の目的は
抜け漏れなくエラー対応してることを
シグニチャーを見ただけでわかるようにして
簡単に静的チェックができるようにするため

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

>>224
いらない情報書かれても読みにくいだけ

**デフォルトの名無しさん** · 2023/01/31(火) 12:44:13.13

今日もpanic警察が必死です。MISRA-C警察みたい

**デフォルトの名無しさん** · 2023/01/31(火) 12:45:18.07

>>225
メモリー不足で動作が保証されないなんて常色だろ
同じくプログラマーの想定外の場合でも動作は保証できないからそういう時は余計なことしないで早期に終了させるしかない
panicってそのためのものだよ
なので個人的にはrustのスタック巻き戻しはやり過ぎだと思ってる

**デフォルトの名無しさん** · 2023/01/31(火) 12:46:06.11

>>230
必要ないと思うなら使わなきゃいいのになぜか鬼の敵みたいになってるの草

**デフォルトの名無しさん** · 2023/01/31(火) 12:47:09.57

panic使う人は使っても困らないような
プログラム開発してるだけ
本人が困ってないならそっとしておけ

**デフォルトの名無しさん** · 2023/01/31(火) 12:51:11.39

panicを使う理由が対応コード書くのがめんどくさいとか見通しとか回復可能でも呼ぶぜってところからきた話なので
回復不能エラーで呼び出された場合とか当たり前なところ話しても議論にもならんやろ

**デフォルトの名無しさん** · 2023/01/31(火) 14:46:39.65

> 本人が困ってないならそっとしておけ
と言いながら構わずに居られない>>233であったw

**デフォルトの名無しさん** · 2023/01/31(火) 15:00:44.42

病院行ったほうがいいよ

**デフォルトの名無しさん** · 2023/01/31(火) 15:03:53.55

>>233
元からそういう話だぞ。panic原理主義者が発狂しているだけで

**デフォルトの名無しさん** · 2023/01/31(火) 15:10:39.60

簡単にpanicされると困るようなプログラム作りたいからこそrust選んだのでは

**デフォルトの名無しさん** · 2023/01/31(火) 15:39:37.08

JavaやC#あたりの経験もなくPythonやJavaScriptしか触ったことがない層がRustをやろうとしてるんだろうな
そうでもないと説明がつかない

**デフォルトの名無しさん** · 2023/01/31(火) 15:48:38.88

言語というよりはエラー種別やドメインエラーをきちんと定義するようなアプリやシステムの開発経験がないからだと思われる

**デフォルトの名無しさん** · 2023/01/31(火) 15:52:55.96

おじおじしてきたな

**デフォルトの名無しさん** · 2023/01/31(火) 16:06:06.73

単発ワラワラw

**デフォルトの名無しさん** · 2023/01/31(火) 16:33:36.83

自分以外がすべて同一人物が書いたかのように見えるなら病院に行きなさいって

**デフォルトの名無しさん** · 2023/01/31(火) 16:45:54.71

複オジ2世レベルやな
立場逆転してるのが感慨深い

**デフォルトの名無しさん** · 2023/01/31(火) 16:51:02.90

そういえばこんなのもあったな
使ってやってくれ

Rustレスバトル会場
https://mevius.5ch.net/test/read.cgi/tech/1657382429/

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

レスバしたいだけにしか見えねえ

**デフォルトの名無しさん** · 2023/01/31(火) 17:26:31.56

GoとかRustとか例外サポートしなくなった言語、標準でスタックトレースサポートしなくなった辛さにみんなどう対応してるのかね。

エラーメッセージで grep とか、ログからコールスタックを想像とか、かなり辛いんですけど。

**デフォルトの名無しさん** · 2023/01/31(火) 17:30:47.95

スタックトレースサポートされてるぞ

だかスタックトレースないとどこでエラーが発生したかわからないような作りは見直すべき

**デフォルトの名無しさん** · 2023/01/31(火) 18:11:46.10

古き良きline!マクロ

**デフォルトの名無しさん** · 2023/01/31(火) 18:25:09.41

c++勉強しているけどやっぱりrustっていいんだな
c++の場合どのオーバーロードが足りないかもエラーをチラ見しながら勘で判断するしかない
少なくとも能力の低いワイはそうやって対処している

**デフォルトの名無しさん** · 2023/01/31(火) 19:05:37.94

例外連呼しているくせに具体的なことを書かない時点でエアプか煽りなんだろうな
例外機構を持つ処理系はエラー処理を局所化できるメリットがある
同様のメリットをRustで得るにはどのような実装が推奨されるんかな？

**デフォルトの名無しさん** · 2023/01/31(火) 19:31:24.49

そこまで言うなら見せてもらおうか。
スレッド間エラー転送とやらを。

**デフォルトの名無しさん** · 2023/01/31(火) 19:36:37.66

https://i.imgur.com/f1bKLY1.png

**デフォルトの名無しさん** · 2023/01/31(火) 19:41:28.43

>>229
Rustの利点に対して「いらない情報」と言い張るのはまるでアンチのように悪意があるなあ
可読性の向上という開発効率でのメリットと実行効率のメリットさらにスレッドやコルーチン実装のタスクからも伝播させることができるRust方式は非常に優れているよ

**デフォルトの名無しさん** · 2023/01/31(火) 19:47:33.31

>>254
だからその情報がなぜ必要なのかを書きなよ
毎回可読性の向上って念仏唱えられても困る

**デフォルトの名無しさん** · 2023/01/31(火) 19:51:16.79

>>247
Rustは標準でスタックトレースをサポートとしている
何でもいいからコンパイルして実行したことあればRUST_BACKTRACE=1と環境変数をセットすれば出力すると表示されることすら知らないのは不思議
ちなみにstd::backtrace::Backtraceによって自由自在に好きなところでバックトレースをキャプチャすることも出来る

**デフォルトの名無しさん** · 2023/01/31(火) 19:56:49.64

>>251
Rustでもエラー処理を上位に委託してエラー処理を一箇所に局所化できる点は全く同じ
いくら初心者でもネット上のBOOKやサンプルや書籍など見てコードを書けばすぐに分かること

**デフォルトの名無しさん** · 2023/01/31(火) 19:58:31.81

>>255
254じゃないけど、メリットは分かりやすいけどなぁ。
関数のインターフェイスに、関数の作用に関する情報がまとまっていたらそりゃ便利だろう。

例外を投げる関数の場合、例外に関する情報は関数のマニュアルを参照するかソースを参照するしかないことがほとんどじゃない？インターフェイスを見ただけで例外を把握できる言語てあったっけ？

**デフォルトの名無しさん** · 2023/01/31(火) 20:06:28.07

ML系の系譜の言語はまあ大体そうなんじゃね

そしてRustでもdyn Errorで返されたら結局同じことやらされる羽目に……

**デフォルトの名無しさん** · 2023/01/31(火) 20:17:47.02

>>258
だから例外に関与しないのになぜそんな情報いるんだ？

**デフォルトの名無しさん** · 2023/01/31(火) 20:25:27.93

>>260
マジでそれ言ってるの？マジで？

例外を無視しても「例外が投げられる」という作用は消えないよ？
例外が投げられても「俺関与しないから」と言って無視するの？

**デフォルトの名無しさん** · 2023/01/31(火) 20:27:00.46

例外に関与しないってどういう意味なんだろう？
ガン無視するって言ってるんだろうか？

**デフォルトの名無しさん** · 2023/01/31(火) 20:36:05.54

>>261-262
いちいち曲解するなよ
下位で発生した例外は何もしなければそのまま上位に伝搬するだろ
例外安全に作られてればその関数で確保したリソースはちゃんと解放される
それは下位の例外の種類に依存しない

**デフォルトの名無しさん** · 2023/01/31(火) 21:10:03.87

>>263
「上位に伝達する」という意味わかっている？
>258がインターフェイスの話をしているのは理解できている？

関数の呼び出し元からすれば、呼び出し先で投げられているのか、さらにその先で投げられているのか、とか関係なく「関数を使ったら例外を投げられた」だよ。関数のユーザーからすれば「投げる例外くらい明確化するのが常識だろ」と思うよな。

関数が例外を投げるのに、その関数の作者が「例外に関与しないからオレ知らね」とか言って逃げたらブチ切れるわ。そんなんだったら例外全部catchして関数の外に漏らすな、と。

**デフォルトの名無しさん** · 2023/01/31(火) 21:16:22.90

>>263
例外安全って意味広すぎて
強い保証したいときとかあるやろ

**デフォルトの名無しさん** · 2023/01/31(火) 21:28:25.11

Javaの検査/非検査例外以降の約20年余りの試行錯誤の結果辿り着いた現時点でのベストプラクティスを採用したのがRustやSwiftのエラー処理モデル

C → Java → C# → Go →Swift/Rust

**デフォルトの名無しさん** · 2023/01/31(火) 21:35:24.95

>>263
そうやって
ヌルポで落ちるプログラムを量産したんだよね

**デフォルトの名無しさん** · 2023/01/31(火) 21:42:42.48

まぁ、Result使うとしてもtry catch finallyブロックみたいなフローが欲しいというのはわからんでもない。

関数から抜ける時にResultを漏らさず処理したいというのはたまにあるし。

**デフォルトの名無しさん** · 2023/01/31(火) 21:48:12.48

>>263
catchとかしないの？回復処理したり付加情報付きの例外投げ直したり
そのためにはcatchすべき例外が上がってくるかどうか知らないといけないんだけど

**デフォルトの名無しさん** · 2023/01/31(火) 22:04:35.47

この件でプログラミング言語が最低限サポートして欲しい点2つ

ある関数(ライブラリ)を使おうとした時に
①その関数やその子孫からエラーや例外が上がってくるのか、それとも全て処理済なのか？
これが奥深く辿らなくても局所的に把握できること
ドキュメントベースはそのミスや見落としが生じるため不可
②エラーや例外が下から上がってくる関数を用いた時に、
その処理をせずに続行してしまうコードを書いてしまったら、実行前に言語システムにより防げること

例えばRustならば①は返値がResult型かどうかですぐに把握できる
②は型システムによりRustコンパイラが型不一致や未処理放置Resultの存在を伝えてくれる
Rustは現在ベストなプログラミング言語と言い切っても過言ではない

**デフォルトの名無しさん** · 2023/01/31(火) 22:16:44.29

>>270
高い信頼性が要求されないプログラムなら
例外と集約エラーハンドラさえあればいいんだから
Rust的なモデルが最適化どうかは要件次第だよ
結局はトレードオフ

**デフォルトの名無しさん** · 2023/01/31(火) 22:19:53.43

>>268
今でもResultを漏らさず処理できると思うんだけど
できないのってどういう状況？

**デフォルトの名無しさん** · 2023/01/31(火) 22:45:41.29

>>271
趣味のおもちゃプログラムでなければ信頼性は必須だよね
それだけでなく>>270の最低限の2点はプログラマーにとっても必要なこと
①を満たせない言語では無駄に調べまくらなければいけない
②を満たせない言語では無駄に実行時デバッグを強いられる
トレードオフと言われても信頼性と開発効率を両方落とすのは割に合わない

**デフォルトの名無しさん** · 2023/01/31(火) 23:47:23.84

使いたい関数だけじゃなくて、その関数が使ってる関数、更にその関数が、、、って調べていかないといけないのが無駄にコスト高になるんだよね。

**デフォルトの名無しさん** · 2023/01/31(火) 23:54:22.59

>>274
使いたい関数のシグニチャ見れば分かることだろ？？？？？

**デフォルトの名無しさん** · 2023/02/01(水) 00:33:02.66

やっぱ複オジは成長しねーな
2世と同類だわ

**デフォルトの名無しさん** · 2023/02/01(水) 03:40:06.80

>>275
それが正しいか信頼できんだろ

**デフォルトの名無しさん** · 2023/02/01(水) 06:17:22.82

>>275
Rustならば使う関数のシグネチャを見ればResultが返ることで>>270の①を知ることができるけど
例外機構の言語の多くはシグネチャには情報がないため完全に信頼できるドキュメントでもない限り下流の関数全調査になるかな
②の処理忘れ防止機能も含めてRustが最も整備されている言語という感じ

**デフォルトの名無しさん** · 2023/02/01(水) 07:12:22.77

>>264
だから上がってくる例外を処理する必要があるならその時に調べればいいでしょ？
例えばprintfみたいな関数作ってる時に下位のputsみたいな関数がI/Oエラーで例外上げてくるだろうけどそれはそのまま上位にあげるだけだろ
いちいち意識する必要はない

>>265
強い保証の意味がよくわからんが自前でキャッチして処理すれば良くね？

>>269
全ての関数で回復処理が必要なわけじゃないし情報を付加するだけなら例外の種類を問わずにキャッチしてスローすればいいでしょ
すべての階層で事細かく例外をキャッチしてスローし直すなんてことは普通やらないよ

**デフォルトの名無しさん** · 2023/02/01(水) 07:21:02.47

>>270
言いたいことはわかるけどそれを実現する手間が掛かりすぎると思う
そもそも例外を上げるかどうかだけを見たいならnoexceptを真面目に実装すればいいだけだし

**デフォルトの名無しさん** · 2023/02/01(水) 08:02:53.27

>>280
それを実現する手間が掛かりすぎる、という視点がむしろ既に間違えているのかもね
従来の例外の枠組みを持たずにRustは>>270の二点をシンプルで効率よく実現してしまった
つまり従来の例外の枠組みよりも利便性と信頼性の高い新たな枠組みが実用的だと示されたのだから
従来の例外の枠組みを捨てるべき時が訪れたと解釈する方が正しいのかもしれない

**デフォルトの名無しさん** · 2023/02/01(水) 08:17:31.54

>>272
あ、漏らさず処理はできるな。ごめん。

言いたいのは「似たようなエラーをまとめておいて、修正も一括で行う」のイメージだった。
例えば「関数内で細切れでファイルに書き込んでいるとき、どこかで書き込みエラーが出たらロールバックしてログを取って再書き込みする」とか。

>>279
やっぱり全然理解できていないな。
その「printfみたいな関数」を使う「上位」のプログラマーはどうすんだよ。「例外に関与しないからオレ知らね」か？
そんなんだったら例外全部catchして関数の外に漏らすな。

**デフォルトの名無しさん** · 2023/02/01(水) 08:17:38.20

>>281
> 従来の例外の枠組みを持たずにRustは>>270の二点をシンプルで効率よく実現してしまった
シンプルだけど生産効率は良くないよね？
って言ってるんだけど...

**デフォルトの名無しさん** · 2023/02/01(水) 08:20:02.84

>>282
上位で処理する必要があるならその時に調べればいいだろ
途中の関数で逐一調べる必要はない
そもそも最下位の関数に新しいエラーが定義されたらrust使いは全部調べ直すのか？

**デフォルトの名無しさん** · 2023/02/01(水) 08:25:05.41

>>279
その調べるかどうかをどう判断するかって話なんだが…
putsがI/Oエラーを上げてくるって知ってるから無視して上に上げるって判断ができるわけ
じゃあライブラリXの関数Yは無視すべきなのかそうでないのか？ってこと