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/ 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 > 例外機構のある言語の多くでは例外が素通りする途中の関数でその宣言をしないためコードを見てもその有無が分からない問題もあった そりゃ途中の関数にはその例外は関係ないからね 関係ないものを見る必要はない 201 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 07:53:28.80 ID:7I30yv0f.net] >>200 コードレビューやリファクタリングや移植作業をしたことがあればそれがコードに見えないことは非常に困ると分かる Rustはそれがはっきりと分かるため可読性が良い 202 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 07:59:50.04 ID:Tm4r8coX.net] mainからリターンするのであればプログラムの終了に至る条件が増えるほどmainの条件分岐がでかくなる ってことも理解できない人がpanicダメとか言っているんだね 203 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 08:27:46.22 ID:cn1TJfcU.net] このスレ見ていると、Rust勉強しているのにコールスタックとかスタックフレームを理解していないやつて意外と多いのが分かるな。 そもそもmainはスタックの根元で、OSとかプログラマーから見てプログラムそのものの代表だろ。 正常なフローならmainで始まってmainで終わるのは定石であって、正常なフローを破壊するpanicは異常事態。 Rustはスタックを重視してResultとか?演算子とか整備しているんだから、わざわざ用途外でpanicを使うのはRustのコンセプトを理解できていない証拠。そんなにスタックフレームのフロー制御が嫌ならRust以外を使ったら？ 204 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 08:35:12.13 ID:7I30yv0f.net] >>202 そもそもpanicするのはメモリ不足くらいしかない それも最近はtry_reserve()などpanicを避ける対応も増えてきたがまだpush_within_capacity()など安定化していないな あと固定サイズ内でやりくりするArrayVecのtry_push()を使うこともよくある 205 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 08:36:17.38 ID:mKWzzzcA.net] 例外がないせいで、複数ライブラリ使うとエラー型を合成する必要があってつらいわ 206 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 08:39:39.26 ID:08CfuspX.net] >>200 入れ子になった関数の途中かどうかなんて関係なく、自身が呼び出した関数から出る例外に無関係な状況など考えにくいんだが 207 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 08:41:05.82 ID:YNMDboNb.net] >>201 何が困るのか具体的に書いてみ 208 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 08:42:54.02 ID:YNMDboNb.net] >>206 自分が関与しない例外なんだろ？ その関数にできることなんてないはずだが？ 209 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 08:43:45.56 ID:7I30yv0f.net] >>205 それは"?"オペレータのところでFrom::from(err)変換が自動適用されるので変換をimplしておけばよいだけ 210 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 08:49:38.58 ID:3fV3plkN.net] panic派の主張は「肥大化するとなんかダサいからエラー処理サボってpanicさせとくわ。コード量は減ってスッキリするから格好いいでしょ」という風にしか聞こえない どれだけ肥大化しようとも想定が必要なエラー処理を省略しては駄目だろう 211 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 08:49:41.53 ID:7I30yv0f.net] >>207 例外がそこを通過するのか否かそこを見ただけで分からないからレビューでもリファクタリングでも何でも不便すぎる 一方でRustはそこがはっきりしていて可読性が良い 未処理な事項があって上位へ処理を委託していると明確に分かる 212 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 08:51:55.45 ID:LXCt1d5H.net] >>205 とりあえず合成したいならanyhow使えばいい 勝手に全部合成されるから使い勝手は例外と変わらんと思うよ 213 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 09:03:32.22 ID:cRk5v+aU.net] >>212 anyhowで勝手に合成されたエラー型への参照をmain()のifで場合分けしようとしたけど JSのinstanceof 演算子的な処理のやり方が分からんかったわ 214 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 09:09:12.08 ID:YNMDboNb.net] >>211 だから不便すぎるとかふわふわした言葉で語るなよw 具体的に何が不便なんだよ 215 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 09:12:07.56 ID:YNMDboNb.net] >>210 panicはバグとかメモリー不足とかでどうしようない状態になったときに呼び出されるもので通常のエラー処理なんてできないってことぐらい理解しなよ 216 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 09:18:10.08 ID:7I30yv0f.net] >>213 そういう使い方をしたいならば例えばライブラリA,B,Cに対してMyErrorをEnumでErrorA,ErrorB,ErrorC各収容した方が扱いやすさも効率も良い そのEnumに格納するだけのコードimpl From<MyError> for ErrorAしておくだけで簡単 217 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 09:23:20.28 ID:cRk5v+aU.net] >>216 全部自動でやってよ 218 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 09:28:45.86 ID:7I30yv0f.net] >>214 Rustでは通過する途中の関数においても"?"オペレータの有無で未処理エラーを上位へ委託しているか否かが明白に分かる だからコードレビューがしやすいし機能追加やリファクタリングする時にも見落としがない 一方で例外機構のある多くの言語では通過する途中の関数を見ても例外が通過するのか否かすら分からない 範囲を大きく広げて探し回らないといけなくなりムダな作業も発生して不便である 219 名前：デフォルトの名無しさん [2023/01/31(火) 10:14:19.93 ID:PU9Vswnw.net] >>205 自分のcrate用にエラーenumを定義して下位のエラーはそれにwrapするんだよ その辺を楽させてくれるのがthiserror カスタムな例外を定義しなくてもBulit-inの例外を使い回すだけで規模の小さいプログラムなら書ける例外+継承のある言語とは違うところ Rustの場合はioエラーのみとかじゃなければ常にエラーenumを書くようになる 220 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 10:15:37.08 ID:YNMDboNb.net] >>218 だから自分が関与しない例外を調べて何をするんだ？ 例外使うなら例外安全に作るのは当たり前でその関数が関与したリソースはその関数がきちんと始末することでなんの問題もないでしょ？ 221 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 10:18:35.43 ID:7I30yv0f.net] >>217 そこは自由度があるから自分で必要性に応じて仕様を決めるべき 完全にサボりたいならanyhow等を使えばよいがその代わりにdynによる非効率さと分類の扱いにくさがトレードオフ 222 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 10:29:38.37 ID:7I30yv0f.net] >>220 中間関数は関与していないのではなくcatchしないことで例外エラーを上位へ移譲している 機能追加やリファクタリングではその処理位置が変わり得るから無関係ではなく把握する必要がある 同じことをRustならば上位への移譲があるか否かが明確に分かるため非常にやりやすい 223 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 10:37:25.48 ID:YNMDboNb.net] >>222 > 機能追加やリファクタリングではその処理位置が変わり得るから無関係ではなく把握する必要がある そりゃその関数が関与するような修正するならな、当たり前 でも全ての関数が毎回関与するわけじゃないだろ なんかダメな理由を必死に探してるとしか思えないけど 224 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 10:41:06.15 ID:7I30yv0f.net] >>223 コードレビューでも同じ 上位への移譲の有無がはっきり分かるRustは可読性が良い 225 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 11:26:55.99 ID:5zDIQfkR.net] メモリ不足でパニックとか言っている時点で全く判かっていないの草 メモリのアロケーションに失敗した場合パニックしてもその動作は保証されない なぜならスタックの巻き戻し中にメモリのアロケーションが試みられないことを保証するのは難しいからだ そのアロケーションに失敗した場合に二重パニックになる パニック時にアボートする場合は別だが、その場合はリソースやロックの開放もれが発生する可能性があるね 226 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 11:52:51.31 ID:df6faTWR.net] >>225 全然ここの話を聞いてなかったけど、C++だとデストラクタは内部で例外を発生しては ならないと決まっているから、デストラクタ内部ではメモリー不足例外も 発生させてはならない。 227 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 11:55:03.20 ID:df6faTWR.net] >>226 [補足] Java などでは、例外を投げるには throw new SomeException(); のようにするが、 C++ では、throw SomeException() のようにする。つまり、前者はヒープから、 後者はスタックから例外オブジェクトを確保する。なので、例外throwそれ自体は メモリー不足にはならない。 228 名前：デフォルトの名無しさん [2023/01/31(火) 11:56:57.46 ID:eIPLUE+9.net] Resultでエラーを表現する一番の目的は 抜け漏れなくエラー対応してることを シグニチャーを見ただけでわかるようにして 簡単に静的チェックができるようにするため 229 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 12:41:27.68 ID:YNMDboNb.net] >>224 いらない情報書かれても読みにくいだけ 230 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 12:44:13.13 ID:+FKSpugG.net] 今日もpanic警察が必死です。MISRA-C警察みたい 231 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 12:45:18.07 ID:YNMDboNb.net] >>225 メモリー不足で動作が保証されないなんて常色だろ 同じくプログラマーの想定外の場合でも動作は保証できないからそういう時は余計なことしないで早期に終了させるしかない panicってそのためのものだよ なので個人的にはrustのスタック巻き戻しはやり過ぎだと思ってる 232 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 12:46:06.11 ID:YNMDboNb.net] >>230 必要ないと思うなら使わなきゃいいのになぜか鬼の敵みたいになってるの草 233 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 12:47:09.57 ID:oegPHy5Y.net] panic使う人は使っても困らないような プログラム開発してるだけ 本人が困ってないならそっとしておけ 234 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 12:51:11.39 ID:CpP2rI02.net] panicを使う理由が対応コード書くのがめんどくさいとか見通しとか回復可能でも呼ぶぜってところからきた話なので 回復不能エラーで呼び出された場合とか当たり前なところ話しても議論にもならんやろ 235 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 14:46:39.65 ID:YNMDboNb.net] > 本人が困ってないならそっとしておけ と言いながら構わずに居られない>>233であったw 236 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 15:00:44.42 ID:hwxs0+db.net] 病院行ったほうがいいよ 237 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 15:03:53.55 ID:ylr44mGO.net] >>233 元からそういう話だぞ。panic原理主義者が発狂しているだけで 238 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 15:10:39.60 ID:3fV3plkN.net] 簡単にpanicされると困るようなプログラム作りたいからこそrust選んだのでは 239 名前：デフォルトの名無しさん [2023/01/31(火) 15:39:37.08 ID:CAp90nIJ.net] JavaやC#あたりの経験もなくPythonやJavaScriptしか触ったことがない層がRustをやろうとしてるんだろうな そうでもないと説明がつかない 240 名前：デフォルトの名無しさん [2023/01/31(火) 15:48:38.88 ID:BgaMS/KG.net] 言語というよりはエラー種別やドメインエラーをきちんと定義するようなアプリやシステムの開発経験がないからだと思われる 241 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 15:52:55.96 ID:+s4b9MNJ.net] おじおじしてきたな 242 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 16:06:06.73 ID:YNMDboNb.net] 単発ワラワラw 243 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 16:33:36.83 ID:hwxs0+db.net] 自分以外がすべて同一人物が書いたかのように見えるなら病院に行きなさいって 244 名前：デフォルトの名無しさん [2023/01/31(火) 16:45:54.71 ID:VKWM6Cjq.net] 複オジ2世レベルやな 立場逆転してるのが感慨深い 245 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 16:51:02.90 ID:+s4b9MNJ.net] そういえばこんなのもあったな 使ってやってくれ Rustレスバトル会場 https://mevius.5ch.net/test/read.cgi/tech/1657382429/ 246 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 17:01:16.78 ID:k74gCp3T.net] レスバしたいだけにしか見えねえ 247 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 17:26:31.56 ID:5mHFhJcn.net] GoとかRustとか例外サポートしなくなった言語、標準でスタックトレースサポートしなくなった辛さにみんなどう対応してるのかね。 エラーメッセージで grep とか、ログからコールスタックを想像とか、かなり辛いんですけど。 248 名前：デフォルトの名無しさん [2023/01/31(火) 17:30:47.95 ID:fFj0kljj.net] スタックトレースサポートされてるぞ だかスタックトレースないとどこでエラーが発生したかわからないような作りは見直すべき 249 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 18:11:46.10 ID:CpP2rI02.net] 古き良きline!マクロ 250 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 18:25:09.41 ID:Qz5B8C78.net] c++勉強しているけどやっぱりrustっていいんだな c++の場合どのオーバーロードが足りないかもエラーをチラ見しながら勘で判断するしかない 少なくとも能力の低いワイはそうやって対処している 251 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 19:05:37.94 ID:Tu8zoz2s.net] 例外連呼しているくせに具体的なことを書かない時点でエアプか煽りなんだろうな 例外機構を持つ処理系はエラー処理を局所化できるメリットがある 同様のメリットをRustで得るにはどのような実装が推奨されるんかな？ 252 名前：デフォルトの名無しさん [2023/01/31(火) 19:31:24.49 ID:p+H/rvZ9.net] そこまで言うなら見せてもらおうか。 スレッド間エラー転送とやらを。 253 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 19:36:37.66 ID:94wkFUZO.net] https://i.imgur.com/f1bKLY1.png 254 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 19:41:28.43 ID:7I30yv0f.net] >>229 Rustの利点に対して「いらない情報」と言い張るのはまるでアンチのように悪意があるなあ 可読性の向上という開発効率でのメリットと実行効率のメリットさらにスレッドやコルーチン実装のタスクからも伝播させることができるRust方式は非常に優れているよ 255 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 19:47:33.31 ID:YNMDboNb.net] >>254 だからその情報がなぜ必要なのかを書きなよ 毎回可読性の向上って念仏唱えられても困る 256 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 19:51:16.79 ID:7I30yv0f.net] >>247 Rustは標準でスタックトレースをサポートとしている 何でもいいからコンパイルして実行したことあればRUST_BACKTRACE=1と環境変数をセットすれば出力すると表示されることすら知らないのは不思議 ちなみにstd::backtrace::Backtraceによって自由自在に好きなところでバックトレースをキャプチャすることも出来る 257 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 19:56:49.64 ID:7I30yv0f.net] >>251 Rustでもエラー処理を上位に委託してエラー処理を一箇所に局所化できる点は全く同じ いくら初心者でもネット上のBOOKやサンプルや書籍など見てコードを書けばすぐに分かること 258 名前：デフォルトの名無しさん mailto:sage [2023/01/31(火) 19:58:31.81 ID:iWzBLVlH.net] >>255 254じゃないけど、メリットは分かりやすいけどなぁ。 関数のインターフェイスに、関数の作用に関する情報がまとまっていたらそりゃ便利だろう。 例外を投げる関数の場合、例外に関する情報は関数のマニュアルを参照するかソースを参照するしかないことがほとんどじゃない？インターフェイスを見ただけで例外を把握できる言語てあったっけ？

---

---

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

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