Rust part19 - 暇つぶし2ch

Rust part19 at TECH

[前50を表示]
200:デフォルトの名無しさん
23/01/31 07:49:11.46 YNMDboNb.net
>>199
> 例外機構のある言語の多くでは例外が素通りする途中の関数でその宣言をしないためコードを見てもその有無が分からない問題もあった
そりゃ途中の関数にはその例外は関係ないからね
関係ないものを見る必要はない

201:デフォルトの名無しさん
23/01/31 07:53:28.80 7I30yv0f.net
>>200
コードレビューやリファクタリングや移植作業をしたことがあればそれがコードに見えないことは非常に困ると分かる
Rustはそれがはっきりと分かるため可読性が良い

202:デフォルトの名無しさん
23/01/31 07:59:50.04 Tm4r8coX.net
mainからリターンするのであればプログラムの終了に至る条件が増えるほどmainの条件分岐がでかくなる
ってことも理解できない人がpanicダメとか言っているんだね

203:デフォルトの名無しさん
23/01/31 08:27:46.22 cn1TJfcU.net
このスレ見ていると、Rust勉強しているのにコールスタックとかスタックフレームを理解していないやつて意外と多いのが分かるな。
そもそもmainはスタックの根元で、OSとかプログラマーから見てプログラムそのものの代表だろ。
正常なフローならmainで始まってmainで終わるのは定石であって、正常なフローを破壊するpanicは異常事態。
Rustはスタックを重視してResultとか?演算子とか整備しているんだから、わざわざ用途外でpanicを使うのはRustのコンセプトを理解できていない証拠。そんなにスタックフレームのフロー制御が嫌ならRust以外を使ったら？

204:デフォルトの名無しさん
23/01/31 08:35:12.13 7I30yv0f.net
>>202
そもそもpanicするのはメモリ不足くらいしかない
それも最近はtry_reserve()などpanicを避ける対応も増えてきたがまだpush_within_capacity()など安定化していないな
あと固定サイズ内でやりくりするArrayVecのtry_push()を使うこともよくある

205:デフォルトの名無しさん
23/01/31 08:36:17.38 mKWzzzcA.net
例外がないせいで、複数ライブラリ使うとエラー型を合成する必要があってつらいわ

206:デフォルトの名無しさん
23/01/31 08:39:39.26 08CfuspX.net
>>200
入れ子になった関数の途中かどうかなんて関係なく、自身が呼び出した関数から出る例外に無関係な状況など考えにくいんだが

207:デフォルトの名無しさん
23/01/31 08:41:05.82 YNMDboNb.net
>>201
何が困るのか具体的に書いてみ

208:デフォルトの名無しさん
23/01/31 08:42:54.02 YNMDboNb.net
>>206
自分が関与しない例外なんだろ？
その関数にできることなんてないはずだが？

209:デフォルトの名無しさん
23/01/31 08:43:45.56 7I30yv0f.net
>>205
それは"?"オペレータのところでFrom::from(err)変換が自動適用されるので変換をimplしておけばよいだけ

210:デフォルトの名無しさん
23/01/31 08:49:38.58 3fV3plkN.net
panic派の主張は「肥大化するとなんかダサいからエラー処理サボってpanicさせとくわ。コード量は減ってスッキリするから格好いいでしょ」という風にしか聞こえない
どれだけ肥大化しようとも想定が必要なエラー処理を省略しては駄目だろう

211:デフォルトの名無しさん
23/01/31 08:49:41.53 7I30yv0f.net
>>207
例外がそこを通過するのか否かそこを見ただけで分からないからレビューでもリファクタリングでも何でも不便すぎる
一方でRustはそこがはっきりしていて可読性が良い
未処理な事項があって上位へ処理を委託していると明確に分かる

212:デフォルトの名無しさん
23/01/31 08:51:55.45 LXCt1d5H.net
>>205
とりあえず合成したいならanyhow使えばいい
勝手に全部合成されるから使い勝手は例外と変わらんと思うよ

213:デフォルトの名無しさん
23/01/31 09:03:32.22 cRk5v+aU.net
>>212
anyhowで勝手に合成されたエラー型への参照をmain()のifで場合分けしようとしたけど
JSのinstanceof 演算子的な処理のやり方が分からんかったわ

214:デフォルトの名無しさん
23/01/31 09:09:12.08 YNMDboNb.net
>>211
だから不便すぎるとかふわふわした言葉で語るなよw
具体的に何が不便なんだよ

215:デフォルトの名無しさん
23/01/31 09:12:07.56 YNMDboNb.net
>>210
panicはバグとかメモリー不足とかでどうしようない状態になったときに呼び出されるもので通常のエラー処理なんてできないってことぐらい理解しなよ

216:デフォルトの名無しさん
23/01/31 09:18:10.08 7I30yv0f.net
>>213
そういう使い方をしたいならば例えばライブラリA,B,Cに対してMyErrorをEnumでErrorA,ErrorB,ErrorC各収容した方が扱いやすさも効率も良い
そのEnumに格納するだけのコードimpl From<MyError> for ErrorAしておくだけで簡単

217:デフォルトの名無しさん
23/01/31 09:23:20.28 cRk5v+aU.net
>>216
全部自動でやってよ

218:デフォルトの名無しさん
23/01/31 09:28:45.86 7I30yv0f.net
>>214
Rustでは通過する途中の関数においても"?"オペレータの有無で未処理エラーを上位へ委託しているか否かが明白に分かる
だからコードレビューがしやすいし機能追加やリファクタリングする時にも見落としがない
一方で例外機構のある多くの言語では通過する途中の関数を見ても例外が通過するのか否かすら分からない
範囲を大きく広げて探し回らないといけなくなりムダな作業も発生して不便である

219:デフォルトの名無しさん
23/01/31 10:14:19.93 PU9Vswnw.net
>>205
自分のcrate用にエラーenumを定義して下位のエラーはそれにwrapするんだよ
その辺を楽させてくれるのがthiserror

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

220:デフォルトの名無しさん
23/01/31 10:15:37.08 YNMDboNb.net
>>218
だから自分が関与しない例外を調べて何をするんだ？
例外使うなら例外安全に作るのは当たり前でその関数が関与したリソースはその関数がきちんと始末することでなんの問題もないでしょ？

221:デフォルトの名無しさん
23/01/31 10:18:35.43 7I30yv0f.net
>>217
そこは自由度があるから自分で必要性に応じて仕様を決めるべき
完全にサボりたいならanyhow等を使えばよいがその代わりにdynによる非効率さと分類の扱いにくさがトレードオフ

222:デフォルトの名無しさん
23/01/31 10:29:38.37 7I30yv0f.net
>>220
中間関数は関与していないのではなくcatchしないことで例外エラーを上位へ移譲している
機能追加やリファクタリングではその処理位置が変わり得るから無関係ではなく把握する必要がある
同じことをRustならば上位への移譲があるか否かが明確に分かるため非常にやりやすい

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

224:デフォルトの名無しさん
23/01/31 10:41:06.15 7I30yv0f.net
>>223
コードレビューでも同じ
上位への移譲の有無がはっきり分かるRustは可読性が良い

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

226:デフォルトの名無しさん
23/01/31 11:52:51.31 df6faTWR.net
>>225
全然ここの話を聞いてなかったけど、C++だとデストラクタは内部で例外を発生しては
ならないと決まっているから、デストラクタ内部ではメモリー不足例外も
発生させてはならない。

227:デフォルトの名無しさん
23/01/31 11:55:03.20 df6faTWR.net
>>226
[補足]
Java などでは、例外を投げるには throw new SomeException(); のようにするが、
C++ では、throw SomeException() のようにする。つまり、前者はヒープから、
後者はスタックから例外オブジェクトを確保する。なので、例外throwそれ自体は
メモリー不足にはならない。

228:デフォルトの名無しさん
23/01/31 11:56:57.46 eIPLUE+9.net
Resultでエラーを表現する一番の目的は
抜け漏れなくエラー対応してることを
シグニチャーを見ただけでわかるようにして
簡単に静的チェックができるようにするため

229:デフォルトの名無しさん
23/01/31 12:41:27.68 YNMDboNb.net
>>224
いらない情報書かれても読みにくいだけ

230:デフォルトの名無しさん
23/01/31 12:44:13.13 +FKSpugG.net
今日もpanic警察が必死です。MISRA-C警察みたい

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

232:デフォルトの名無しさん
23/01/31 12:46:06.11 YNMDboNb.net
>>230
必要ないと思うなら使わなきゃいいのになぜか鬼の敵みたいになってるの草

233:デフォルトの名無しさん
23/01/31 12:47:09.57 oegPHy5Y.net
panic使う人は使っても困らないような
プログラム開発してるだけ
本人が困ってないならそっとしておけ

234:デフォルトの名無しさん
23/01/31 12:51:11.39 CpP2rI02.net
panicを使う理由が対応コード書くのがめんどくさいとか見通しとか回復可能でも呼ぶぜってところからきた話なので
回復不能エラーで呼び出された場合とか当たり前なところ話しても議論にもならんやろ

235:デフォルトの名無しさん
23/01/31 14:46:39.65 YNMDboNb.net
> 本人が困ってないならそっとしておけ
と言いながら構わずに居られない>>233であったw

236:デフォルトの名無しさん
23/01/31 15:00:44.42 hwxs0+db.net
病院行ったほうがいいよ

237:デフォルトの名無しさん
23/01/31 15:03:53.55 ylr44mGO.net
>>233
元からそういう話だぞ。panic原理主義者が発狂しているだけで

238:デフォルトの名無しさん
23/01/31 15:10:39.60 3fV3plkN.net
簡単にpanicされると困るようなプログラム作りたいからこそrust選んだのでは

239:デフォルトの名無しさん
23/01/31 15:39:37.08 CAp90nIJ.net
JavaやC#あたりの経験もなくPythonやJavaScriptしか触ったことがない層がRustをやろうとしてるんだろうな
そうでもないと説明がつかない

240:デフォルトの名無しさん
23/01/31 15:48:38.88 BgaMS/KG.net
言語というよりはエラー種別やドメインエラーをきちんと定義するようなアプリやシステムの開発経験がないからだと思われる

241:デフォルトの名無しさん
23/01/31 15:52:55.96 +s4b9MNJ.net
おじおじしてきたな

242:デフォルトの名無しさん
23/01/31 16:06:06.73 YNMDboNb.net
単発ワラワラw

243:デフォルトの名無しさん
23/01/31 16:33:36.83 hwxs0+db.net
自分以外がすべて同一人物が書いたかのように見えるなら病院に行きなさいって

244:デフォルトの名無しさん
23/01/31 16:45:54.71 VKWM6Cjq.net
複オジ2世レベルやな
立場逆転してるのが感慨深い

245:デフォルトの名無しさん
23/01/31 16:51:02.90 +s4b9MNJ.net
そういえばこんなのもあったな
使ってやってくれ
Rustレスバトル会場
ｽﾚﾘﾝｸ(tech板)

246:デフォルトの名無しさん
23/01/31 17:01:16.78 k74gCp3T.net
レスバしたいだけにしか見えねえ

247:デフォルトの名無しさん
23/01/31 17:26:31.56 5mHFhJcn.net
GoとかRustとか例外サポートしなくなった言語、標準でスタックトレースサポートしなくなった辛さにみんなどう対応してるのかね。
エラーメッセージで grep とか、ログからコールスタックを想像とか、かなり辛いんですけど。

248:デフォルトの名無しさん
23/01/31 17:30:47.95 fFj0kljj.net
スタックトレースサポートされてるぞ
だかスタックトレースないとどこでエラーが発生したかわからないような作りは見直すべき

249:デフォルトの名無しさん
23/01/31 18:11:46.10 CpP2rI02.net
古き良きline!マクロ

250:デフォルトの名無しさん
23/01/31 18:25:09.41 Qz5B8C78.net
c++勉強しているけどやっぱりrustっていいんだな
c++の場合どのオーバーロードが足りないかもエラーをチラ見しながら勘で判断するしかない
少なくとも能力の低いワイはそうやって対処している

251:デフォルトの名無しさん
23/01/31 19:05:37.94 Tu8zoz2s.net
例外連呼しているくせに具体的なことを書かない時点でエアプか煽りなんだろうな
例外機構を持つ処理系はエラー処理を局所化できるメリットがある
同様のメリットをRustで得るにはどのような実装が推奨されるんかな？

252:デフォルトの名無しさん
23/01/31 19:31:24.49 p+H/rvZ9.net
そこまで言うなら見せてもらおうか。
スレッド間エラー転送とやらを。

253:デフォルトの名無しさん
23/01/31 19:36:37.66 94wkFUZO.net
URLﾘﾝｸ(i.imgur.com)

254:デフォルトの名無しさん
23/01/31 19:41:28.43 7I30yv0f.net
>>229
Rustの利点に対して「いらない情報」と言い張るのはまるでアンチのように悪意があるなあ
可読性の向上という開発効率でのメリットと実行効率のメリットさらにスレッドやコルーチン実装のタスクからも伝播させることができるRust方式は非常に優れているよ

255:デフォルトの名無しさん
23/01/31 19:47:33.31 YNMDboNb.net
>>254
だからその情報がなぜ必要なのかを書きなよ
毎回可読性の向上って念仏唱えられても困る

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

257:デフォルトの名無しさん
23/01/31 19:56:49.64 7I30yv0f.net
>>251
Rustでもエラー処理を上位に委託してエラー処理を一箇所に局所化できる点は全く同じ
いくら初心者でもネット上のBOOKやサンプルや書籍など見てコードを書けばすぐに分かること

258:デフォルトの名無しさん
23/01/31 19:58:31.81 iWzBLVlH.net
>>255
254じゃないけど、メリットは分かりやすいけどなぁ。
関数のインターフェイスに、関数の作用に関する情報がまとまっていたらそりゃ便利だろう。
例外を投げる関数の場合、例外に関する情報は関数のマニュアルを参照するかソースを参照するしかないことがほとんどじゃない？インターフェイスを見ただけで例外を把握できる言語てあったっけ？

259:デフォルトの名無しさん
23/01/31 20:06:28.07 0vRdrBrN.net
ML系の系譜の言語はまあ大体そうなんじゃね
そしてRustでもdyn Errorで返されたら結局同じことやらされる羽目に……

260:デフォルトの名無しさん
23/01/31 20:17:47.02 YNMDboNb.net
>>258
だから例外に関与しないのになぜそんな情報いるんだ？

261:デフォルトの名無しさん
23/01/31 20:25:27.93 QTaicIN8.net
>>260
マジでそれ言ってるの？マジで？
例外を無視しても「例外が投げられる」という作用は消えないよ？
例外が投げられても「俺関与しないから」と言って無視するの？

262:デフォルトの名無しさん
23/01/31 20:27:00.46 1QZESm3t.net
例外に関与しないってどういう意味なんだろう？
ガン無視するって言ってるんだろうか？

263:デフォルトの名無しさん
23/01/31 20:36:05.54 YNMDboNb.net
>>261-262
いちいち曲解するなよ
下位で発生した例外は何もしなければそのまま上位に伝搬するだろ
例外安全に作られてればその関数で確保したリソースはちゃんと解放される
それは下位の例外の種類に依存しない

264:デフォルトの名無しさん
23/01/31 21:10:03.87 QTaicIN8.net
>>263
「上位に伝達する」という意味わかっている？
>258がインターフェイスの話をしているのは理解できている？
関数の呼び出し元からすれば、呼び出し先で投げられているのか、さらにその先で投げられているのか、とか関係なく「関数を使ったら例外を投げられた」だよ。関数のユーザーからすれば「投げる例外くらい明確化するのが常識だろ」と思うよな。
関数が例外を投げるのに、その関数の作者が「例外に関与しないからオレ知らね」とか言って逃げたらブチ切れるわ。そんなんだったら例外全部catchして関数の外に漏らすな、と。

265:デフォルトの名無しさん
23/01/31 21:16:22.90 1QZESm3t.net
>>263
例外安全って意味広すぎて
強い保証したいときとかあるやろ

266:デフォルトの名無しさん
23/01/31 21:28:25.11 Qz/Q1rYV.net
Javaの検査/非検査例外以降の約20年余りの試行錯誤の結果辿り着いた現時点でのベストプラクティスを採用したのがRustやSwiftのエラー処理モデル
C → Java → C# → Go →Swift/Rust

267:デフォルトの名無しさん
23/01/31 21:35:24.95 Mxurit6u.net
>>263
そうやって
ヌルポで落ちるプログラムを量産したんだよね

268:デフォルトの名無しさん
23/01/31 21:42:42.48 QTaicIN8.net
まぁ、Result使うとしてもtry catch finallyブロックみたいなフローが欲しいというのはわからんでもない。
関数から抜ける時にResultを漏らさず処理したいというのはたまにあるし。

269:デフォルトの名無しさん
23/01/31 21:48:12.48 jD2BQUnk.net
>>263
catchとかしないの？回復処理したり付加情報付きの例外投げ直したり
そのためにはcatchすべき例外が上がってくるかどうか知らないといけないんだけど

270:デフォルトの名無しさん
23/01/31 22:04:35.47 WaCEL3Yw.net
この件でプログラミング言語が最低限サポートして欲しい点2つ
ある関数(ライブラリ)を使おうとした時に
①その関数やその子孫からエラーや例外が上がってくるのか、それとも全て処理済なのか？
これが奥深く辿らなくても局所的に把握できること
ドキュメントベースはそのミスや見落としが生じるため不可
②エラーや例外が下から上がってくる関数を用いた時に、
その処理をせずに続行してしまうコードを書いてしまったら、実行前に言語システムにより防げること
例えばRustならば①は返値がResult型かどうかですぐに把握できる
②は型システムによりRustコンパイラが型不一致や未処理放置Resultの存在を伝えてくれる
Rustは現在ベストなプログラミング言語と言い切っても過言ではない

271:デフォルトの名無しさん
23/01/31 22:16:44.29 Mxurit6u.net
>>270
高い信頼性が要求されないプログラムなら
例外と集約エラーハンドラさえあればいいんだから
Rust的なモデルが最適化どうかは要件次第だよ
結局はトレードオフ

272:デフォルトの名無しさん
23/01/31 22:19:53.43 Mxurit6u.net
>>268
今でもResultを漏らさず処理できると思うんだけど
できないのってどういう状況？

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

274:デフォルトの名無しさん
23/01/31 23:47:23.84 ovWek0QN.net
使いたい関数だけじゃなくて、その関数が使ってる関数、更にその関数が、、、って調べていかないといけないのが無駄にコスト高になるんだよね。

275:デフォルトの名無しさん
23/01/31 23:54:22.59 hwxs0+db.net
>>274
使いたい関数のシグニチャ見れば分かることだろ？？？？？

276:デフォルトの名無しさん
23/02/01 00:33:02.66 CK4ZTpUy.net
やっぱ複オジは成長しねーな
2世と同類だわ

277:デフォルトの名無しさん
23/02/01 03:40:06.80 RyGmTTdX.net
>>275
それが正しいか信頼できんだろ

278:デフォルトの名無しさん
23/02/01 06:17:22.82 5NtLPUR3.net
>>275
Rustならば使う関数のシグネチャを見ればResultが返ることで >>270の①を知ることができるけど
例外機構の言語の多くはシグネチャには情報がないため完全に信頼できるドキュメントでもない限り下流の関数全調査になるかな
②の処理忘れ防止機能も含めてRustが最も整備されている言語という感じ

279:デフォルトの名無しさん
23/02/01 07:12:22.77 Hf88nfPH.net
>>264
だから上がってくる例外を処理する必要があるならその時に調べればいいでしょ？
例えばprintfみたいな関数作ってる時に下位のputsみたいな関数がI/Oエラーで例外上げてくるだろうけどそれはそのまま上位にあげるだけだろ
いちいち意識する必要はない
 >>265
強い保証の意味がよくわからんが自前でキャッチして処理すれば良くね？
>>269
全ての関数で回復処理が必要なわけじゃないし情報を付加するだけなら例外の種類を問わずにキャッチしてスローすればいいでしょ
すべての階層で事細かく例外をキャッチしてスローし直すなんてことは普通やらないよ

280:デフォルトの名無しさん
23/02/01 07:21:02.47 Hf88nfPH.net
>>270
言いたいことはわかるけどそれを実現する手間が掛かりすぎると思う
そもそも例外を上げるかどうかだけを見たいならnoexceptを真面目に実装すればいいだけだし

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

282:デフォルトの名無しさん
23/02/01 08:17:31.54 rokbXrwB.net
>>272
あ、漏らさず処理はできるな。ごめん。

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

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

283:デフォルトの名無しさん
23/02/01 08:17:38.20 Hf88nfPH.net
>>281
> 従来の例外の枠組みを持たずにRustは>>270の二点をシンプルで効率よく実現してしまった
シンプルだけど生産効率は良くないよね？
って言ってるんだけど...

284:デフォルトの名無しさん
23/02/01 08:20:02.84 Hf88nfPH.net
>>282
上位で処理する必要があるならその時に調べればいいだろ
途中の関数で逐一調べる必要はない
そもそも最下位の関数に新しいエラーが定義されたらrust使いは全部調べ直すのか？

285:デフォルトの名無しさん
23/02/01 08:25:05.41 ATJMUMOg.net
>>279
その調べるかどうかをどう判断するかって話なんだが…
putsがI/Oエラーを上げてくるって知ってるから無視して上に上げるって判断ができるわけ
じゃあライブラリXの関数Yは無視すべきなのかそうでないのか？ってこと

286:デフォルトの名無しさん
23/02/01 08:27:52.62 rokbXrwB.net
>>284
どうやって調べるのか、具体的に考えた？
インターフェイスしか提供されていなくて、ソースコードの無いライブラリとかでどうやって調べるの？

エスパーか神様でもなければ不可能だね。

287:デフォルトの名無しさん
23/02/01 08:30:01.09 5NtLPUR3.net
>>283
むしろ >>270の二点をサポートしているRustは開発効率が高いでしょう
それらをサポート出来ていない従来のプログラミング言語は開発効率も信頼性も低いわけです
開発効率と実行効率と信頼性の高さを両立させたRustの地位は揺るぎないと思われます

288:デフォルトの名無しさん
23/02/01 08:37:05.02 rokbXrwB.net
ダックタイプ系の開発効率を求めるならRustは選択すべきじゃないよね。メモリの取り扱い見ればRustは「作法を強制する言語」だということは明らか。
そういうのはPythonとかRubyとかスクリプト言語があるんだからそっちを選ぶべき。

289:デフォルトの名無しさん
23/02/01 08:41:21.89 wznv5J1H.net
>> 279
> 強い保証の意味がよくわからんが自前でキャッチして処理すれば良くね？
他は既に突っ込まれてるから言わんが
例外に関するプログラミングしてたらすぐにわかる概念だからググれ
つうか例外安全って言葉使うなら知っとけ

290:デフォルトの名無しさん
23/02/01 08:54:40.02 Hf88nfPH.net
>>285
例えばprintfみたいな関数で下位の例外を処理するのか？
処理するとして何をやるんだ？
って話
考え方が逆なの、自分に関与しない例外は触らない
 >>286
ライブラリならドキュメントに書いてあるでしょ
 >>287
また呪文唱え始めたのかw
せめてこれに答えてよ
> そもそも最下位の関数に新しいエラーが定義されたらrust使いは全部調べ直すのか？

291:デフォルトの名無しさん
23/02/01 08:55:45.56 Hf88nfPH.net
>>289
> 例外に関するプログラミングしてたらすぐにわかる概念だからググれ
また無能のググれかよw
答えられないなら無駄に絡んでくるなよ

292:デフォルトの名無しさん
23/02/01 08:58:06.40 ATJMUMOg.net
>>290
別に調べ直す必要はないよ
下位にエラーが追加されても直接呼び出す関数のシグネチャが変わらないなら対応不要、変わったら対応するってだけ
結局呼び出す関数のResult型が対応すべきもののすべてなんだからそれ以外見る必要がない

293:デフォルトの名無しさん
23/02/01 09:02:33.17 JRuvbVor.net
>>288
そういうCPUもメモリも浪費するエコでない言語との比較はほとんど意味がないんじゃないかな
GC言語であってもそこそこ速いJavaやGoくらいの立ち位置の言語ならば比較の意味があるとしても

294:デフォルトの名無しさん
23/02/01 09:20:03.74 JRuvbVor.net
>>290
> そもそも最下位の関数に新しいエラーが定義されたらrust使いは全部調べ直すのか？

Rustでそんなことをする必要がないよ
元々他のエラーも返す関数だったならば返り値型が元々Result型だから枠組みは変化なし
新たにエラーを返すように返り値型が変わったならばコンパイルエラーで気付く

295:デフォルトの名無しさん
23/02/01 09:26:13.19 ypE1x0h9.net
fishシェルをRustで書き直すことが（ほぼ）決まったよ
URLﾘﾝｸ(github.com)

C++ と CMakeをかなり腐してるけど意外に荒れてない
ちなみに提案者は開発リーダーなのでほぼ決まりでしょう
リンクされてる移行プランは他のプロジェクトでも参考になりそう

296:デフォルトの名無しさん
23/02/01 12:36:36.73 o2DBVRIO.net
>>292,294
> 元々他のエラーも返す関数だったならば返り値型が元々Result型だから枠組みは変化なし
なら、その新しいエラー（例えばディスクフルを検出してたが今回ディスクオフラインなんてエラーが追加された）の処理が抜けてないことはどうやってわかるんだ？
実行時にしかわからないなら例外と変わらん
むしろ途中の伝搬コードをいちいち書くのが面倒なだけだろ

297:デフォルトの名無しさん
23/02/01 12:42:13.45 BH4poKX+.net
Elixir にも、try/rescue の例外があるけど、あまり使わない。
throw/catch, raise でも、例外の発生場所を関数の外側から内側へ移すだけ
try do
%{a: a} = map
{:ok, a}
rescue
MatchError -> {:error, ":a が無い"}
end
とは書かずに、パターンマッチで書くのがElixir流
case map do
%{a: a} -> {:ok, a}
_ -> {:error, ":a が無い"}
end

298:297
23/02/01 12:45:24.97 BH4poKX+.net
>>297
修正。内側・外側が逆だった
>throw/catch, raise でも、例外の発生場所を関数の外側から内側へ移すだけ
throw/catch, raise でも、例外の発生場所を関数の内側から外側へ移すだけ

299:デフォルトの名無しさん
23/02/01 14:01:39.16 TUW+NsdV.net
>>296
それはResult<T,E>のEで返されるエラーenumのvariantが増えるだけ
んでvariantが増えればEをハンドルしてるところでexhaustiveに処理してなければコンパイルエラー

300:デフォルトの名無しさん
23/02/01 14:08:16.76 w5pt5x/h.net
>>282
>言いたいのは「似たようなエラーをまとめておいて、修正も一括で行う」のイメージだった。
これはResultのコレクションを返せばいい
例外のある言語でもこのケースは例外じゃなくエラー情報を貯めたオブジェクトを戻り値で返してエラーがあったかどうかをチェックして分岐するコードを書く
それと似たようなもの
>例えば「関数内で細切れでファイルに書き込んでいるとき、どこかで書き込みエラーが出たらロールバックしてログを取って再書き込みする」とか。
ロールバックする系の処理ならエラーを貯めずにエラーが一つ出た時点で中断するように作ったほうがいい

301:デフォルトの名無しさん
23/02/01 15:31:55.23 4CkJdapD.net
脳死でdyn Error突っ込んでるやつです

302:デフォルトの名無しさん
23/02/01 15:34:50.34 ypE1x0h9.net
dyn Errorで受け取った後の活用法が分からん

303:デフォルトの名無しさん
23/02/01 17:49:22.59 HDxpsRMp.net
dyn Errorでできるのは
・print!とかwrite!でログ出力する
（ErrorトレイトにDebugとDisplayが内包されてるからちゃんと実装されてれば何か教えてくれる）
・source()で内部のdyn Errorを掘り起こす
（エラーの原因のエラーがあれば一緒にログ出力できる）
くらいだからログ出力以上の活用がしたいならそのためのError型を使わないといけない

304:デフォルトの名無しさん
23/02/01 18:15:38.74 pHJayYFi.net
>>302
具体的なエラーの型で分岐させたいならダウンキャストが必要(The Bookにも書いてたはず)
エラーenumを定義してwrapしたものに変換(map_err)しておけばダウンキャストは不要
anyhowに組み合わせてthiserrorの#[from]や#[error(transparent)]を使うと楽にwrapできる
anyhow/thiserrorのやってることに最初から自力で辿り着くのは大変だから先に使ってみて必要な要素を学んだ方が早いよ

305:デフォルトの名無しさん
23/02/01 19:06:46.56 JRuvbVor.net
>>303
dynはErrorに限らず自由に元へ戻せるよ
例えばstd::io::Errorを含むdyn Errorが返ってきた時
if let Some(io_err) = dyn_err.downcast_ref::<io::Error>() {
　match io_err.kind() {
　　io::ErrorKind::NotFound => {
このように細かいエラーハンドリングが可能
 >>304
順序が逆だよ
まずは標準ライブラリ内で上記のようにdyn Errorを使ったり
あるいはdynを使わずにimpl From<MyError> for io::ErrorでMyErrorのEnumに格納する「?」時の自動変換を書いたり
それぞれ簡単で単純なパターンなのだから標準ライブラリで基礎を身に着けた上で自作や外部のライブラリを選ぶのがお勧め

306:デフォルトの名無しさん
23/02/01 19:07:10.38 sE34HuOS.net
>>290
例外をサポートしているような言語なら、投げる例外を関数のインターフェイスとしてドキュメントに記載する。
Rustなら >>292

>考え方が逆なの、自分に関与しない例外は触らない
>290が>285 >286を理解できない無能だということは理解できた。
c++とかでライブラリ関数からドキュメントに無い例外を投げられた経験が無いんだろうな。おめでたい。

307:デフォルトの名無しさん
23/02/01 19:18:58.38 RjOpz7Dl.net
単発無能認定おじさん

308:デフォルトの名無しさん
23/02/01 19:27:56.01 JRuvbVor.net
>> ライブラリならドキュメントに書いてあるでしょ
ドキュメントは言語システムの一部ではないため
ミスで現実のコードとドキュメントが食い違っていることもあれば
ドキュメントは正しくても利用者が見落としてしまうこともある
大規模な開発になればなるほどミスや見落としが紛れ込むことは避けられない
特にエラー処理が済んでいるか未だなのかは致命的になりかねない
一方でRustは言語システムの中で下位関数からエラーが上がってくるか処理済か分かる
さらにResultが未処理のままだとRustコンパイラが指摘してくれる
言語システムとして少なくともこれらの機能を持つ言語へと今後は移行していくべき流れ

309:デフォルトの名無しさん
23/02/01 21:57:57.91 qgBIsers.net
>>305
>それぞれ簡単で単純なパターンなのだから
実装の簡単さやパターンの単純さが問題じゃないんだよ
Rustのエラー処理に必要な「それぞれ簡単で単純なパターン」を網羅的に知識として仕入れてRustのエラー処理はこうやってやるものだと自信を持って言えるようになるまでの学習効率の問題
anyhow/thiserrorはそのパターンを楽に使えるよう作られてるから「ああRustのエラー処理ってこうやればいいんだな」ってのが標準ライブラリ前提で学ぶより断然早く理解できる

310:デフォルトの名無しさん
23/02/01 22:05:04.46 JRuvbVor.net
>>309
dynの取り扱いと「?」オペレータによる自動変換はRustの基本事項で必須の知識
もちろん標準ライブラリの中で完結して使えるしシンプル仕組みなのですぐ使えるようになる
この基本を習得せずに外部ライブラリへ行くことを勧めるのは基本知識を欠いた人を生み出してしまう愚かな行為

311:デフォルトの名無しさん
23/02/01 22:25:39.32 JqtaL/Do.net
>>310
もしかしてパターンってdyn Errorと?オペレータ使った自動変換の話だけなの？
それだけじゃRustで現実的にどうエラー処理を実装すべきかThe Book読み終えたくらいの人にはわかんないと思うよ

312:デフォルトの名無しさん
23/02/01 22:59:41.62 JRuvbVor.net
>>311
エラー処理パターンは様々な方針があり
その前提知識としての共通の必須事項として今回のスレの流れで話が出て来ていたdynの取り扱いと?での自動変換の話を書いた
例えばあなたが出したanyhowはdyn Errorを扱う外部ライブラリの一種
anyhow::Errorから具体的な型を取り出すためには >>305で書いたdynの取り扱い知識が必須
この知識を知らないと細かいエラー分類が出来ずにエラー表示のみしか出来ない人になってしまう
もう一つあなたが出したthiserrorも?での自動変換を用いる外部ライブラリ(というかマクロ)の一種
 >>305で示したFrom::from()による自動変換の基礎知識を欠いたままでは仕組みすら分からず魔法のように外部ライブラリを使うダメな人になってしまう
応用が効かないだけでなく利用していて何か問題にハマった時に基本知識がないと解決することもできない

313:デフォルトの名無しさん
23/02/02 00:32:13.04 y8eaHXgz.net
>>312
設計やプラクティスとしてのパターンのことを言ってたんだが君は言語機能のことをパターンと呼んでるみたいで噛み合ってないよね
dyn Errorや?オペレータ使ってinto経由で変換されるような基本的な機能面の知識はThe Bookにも書かれてるレベルだし多少分からなくてもリファレンス読めばいいだけの話
でもそれだけの知識でRust初心者がエラー周りの実践的な設計をできるようにはならないでしょ

314:デフォルトの名無しさん
23/02/02 00:53:57.92 tzaW+blt.net
anyhow/thiserrorは最近出てきた新興ライブラリ
当然それまでは誰も使っていなかったわけで初心者がいきなり必須なものでもない
初心者にとっては複雑で機能過多で理解しにくいのでまずは標準ライブラリから始めたほうが良いかな

315:デフォルトの名無しさん
23/02/02 01:38:05.78 JL6WsU2I.net
対象年齢付きのおもちゃか何か？w
自分だけ勝手に縛ってろw

316:デフォルトの名無しさん
23/02/02 03:39:28.87 S9qGtTXE.net
Rustは「教官付き教習車」だよ。
cとかと違ってアホが膝を撃ち抜く自由は許さない。
それが嫌ならRust止めれば？

317:デフォルトの名無しさん
23/02/02 07:11:05.90 02L2EQ2o.net
Rustはコンパイラの防波堤の中で安全な自由があるけどそれはともかく
クセの強いanyhowをRustの基本より先に初心者に教えるのはあかんよ
たとえば、他人も使うライブラリ作成ではanyhowの使用を避ける、といった当たり前のことも
エラーに関する基本を知らないと陥ってしまう

318:デフォルトの名無しさん
23/02/02 07:31:00.57 c3pJ+FwE.net
>>316
rustの免許とりたいんですがおすすめの教習所はありますか？w

319:デフォルトの名無しさん
23/02/02 07:34:23.41 /W20jYzd.net
anyhowはもはや標準ライブラリでしょ

320:デフォルトの名無しさん
23/02/02 07:55:32.16 Cx26n0QZ.net
>>317
あれはクセというよりanyhowの致命的な欠陥だ
分かってる人は配慮して閉じた環境だけで使うけど稀に公開ライブラリにanyhow使っちゃう無知な人もいる
基礎知識はホント一番大事

321:デフォルトの名無しさん
23/02/02 08:05:47.28 VrfwqxiC.net
>>318
コンパイラ(教官)はひとつしか無いから選択肢は無いよ。

322:デフォルトの名無しさん
23/02/02 08:14:13.18 eMZEpDOV.net
コードを貼るわけでも実装例を示すわけでもない時点でシッタカだろ

323:デフォルトの名無しさん
23/02/02 09:11:33.63 ICVq01Bq.net
anyhow勧めてる人自身があんまり理解してないんだと思う

324:デフォルトの名無しさん
23/02/02 12:40:03.75 8vdGQp5R.net
複オジが使ったことないだけだろ
 >>312も今調べてきました感満載じゃん
デファクトスタンダードになってるライブラリまで排除したらrustでは何もできんぞ

325:デフォルトの名無しさん
23/02/02 12:47:49.51 YyXCj6j+.net
オライリー本にも実戦ではanyhowとthiserrorを使えと書いてる

326:デフォルトの名無しさん
23/02/02 12:59:53.51 c3pJ+FwE.net
>>321
うまいこといいますね。お見事！

327:デフォルトの名無しさん
23/02/02 13:20:28.44 C8PK02xw.net
禁忌事項はライブラリを作って提供する時にanyhowを使ってしまうことだけだから
そこはanyhowを使わずにthiserrorを使えばヨシ

328:デフォルトの名無しさん
23/02/02 15:47:50.42 HD9HoUeH.net
別にanyhowをthiserrorに差し替えるのも大した手間じゃないしな
ライブラリで使っちゃってるなら変更PRでも出してやれば良い

329:デフォルトの名無しさん
23/02/02 23:07:11.98 3wRXRcn7.net
>>325
anyhowとthiserrorを使うなと言ってる人は誰もいなくて
・まず先にstd::error::Errorを覚えよう
・次に?変換とdynダウンキャストを覚えよう
・そしてanyhowとthiserrorへ進もう
という話でしょ
そうすればanyhowをライブラリで使うべきでない理由もわかるでしょうし

330:デフォルトの名無しさん
23/02/02 23:14:43.66 3quZbai0.net
Rustの世界でダウンキャストってなんかキモいな

331:デフォルトの名無しさん
23/02/02 23:37:26.35 wswA48V7.net
むしろRust基盤の一つ
downcastはエラー処理に限らずdyn Traitを元の型に戻すために必須
anyhowでも元のエラー型に戻すために必須

332:デフォルトの名無しさん
23/02/02 23:53:43.61 86yN0Q3V.net
ダウンキャストのソース見てみたら
やっぱりunsafeのかたまりだった

333:デフォルトの名無しさん
23/02/02 23:53:52.64 QEJ+oT50.net
ダウンキャストを知らないと
 >>303のようにdyn Errorで出来ることはログ出力だけと思いこんでしまう

334:デフォルトの名無しさん
23/02/02 23:59:01.23 Cx26n0QZ.net
>>332
当たり前
Rustの標準ライブラリはunsafeだらけ
原理的にunsafeは避けられないからそれを安全なインターフェイスとして公開するのがRustの標準ライブラリ

335:デフォルトの名無しさん
23/02/03 00:57:17.44 teLYlQt8.net
dynを元の型に戻すという発想に違和感（気持ち悪さ）を感じる人もいると思う
元の型に戻すつもりならそもそもdynにしないというか
ダウンキャストは戻すべき型（の変更）を全部把握できる閉じた状況じゃないと使いにくい

336:デフォルトの名無しさん
23/02/03 01:37:41.39 VgIBWdEw.net
>>335
anyhowを使うのはそういう全部把握できる閉じた状況で
独自エラー型を用意するのが面倒な時に使うからダウンキャストが理に適っている
嫌ならanyhow使わずにthiserrorを使えばよい

次ページ