C vs C++ vs Rust Part.2

**デフォルトの名無しさん** · 2021/12/15(水) 12:35:50.91

競え
※前スレ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

**デフォルトの名無しさん** · 2022/01/13(木) 16:20:05.76

>>606
Rustなら色々やり方あろうけど、わかりやすい例にするとこうなる。

fn main() {
match sub() {
Ok(result) => { commit(); println!("OK: {}", result); },
Err(err) => { rollback(); println!("ERROR: {}", err); },
}
}

sub() -> Result<DataType, Error> {
let a = foo()?;
let b = bar()?;
baz(a, b)
}

foo(), bar(), baz()各々はResultでエラー値も同時に返しているが、エラーチェックはまとめて出来る。
ResultはOkとErrの2つを取るenumであり、matchは強力なswitch相当と思っていただければいい。
try catchといった例外処理がなくてもプログラミングで困ることはない。

**デフォルトの名無しさん** · 2022/01/13(木) 16:27:12.94

>>609
> べき論の話で言ったらC++もエラー処理には戻り値を使うべき

>>606 のコードをこんな感じで書くの？

int process()
{
　　if (foo() != 0)
　　　　return -1;
　　if (bar() != 0)
　　　　return -1;
　　if (baz() != 0)
　　　　return -1;
　　return 0;
}

int hoge()
{
　　if (begin() != 0)
　　　　return -1;
　　int ret = porcess();
　　if (ret == 0) {
　　　　if (commit() = 0)
　　　　　　return 0;
　　}
　　(void)rollback();
　　return -1;
}

**デフォルトの名無しさん** · 2022/01/13(木) 16:28:29.38

>>610
> foo(), bar(), baz()各々はResultでエラー値も同時に返しているが、エラーチェックはまとめて出来る。
できないよ。
失敗した段階で処理を中止する必要がある。

**デフォルトの名無しさん** · 2022/01/13(木) 16:36:22.32

あ、ひょっとして「?;」ってエラーが発生したらそこでsub()を抜けるってこと？
まあ、だとしても、C++でもエラーチェックベースで実装しろということにはならないけどね

**デフォルトの名無しさん** · 2022/01/13(木) 16:42:23.86

大抵の言語では、例外が発生したらスタックトレースが取れたり、例外オブジェクトそのものにエラー発生場所・エラーコード・エラーメッセージなんかが入ってたりするから、使わない手はないと思うよ

**デフォルトの名無しさん** · 2022/01/13(木) 16:57:19.52

>>611
その場合でも、Rustならば戻り値をResultにしてこのように見やすくプログラミングしやすい。

fn process() -> Result<(), Error> {
　foo()?;
　bar()?;
　baz()
}

fn hoge() -> Result<(), Error> {
　begin()?;
　match process() {
　　Ok(()) => {
　　　commit()?;
　　　Ok(())
　　},
　　Err(err) => {
　　　rollback();
　　　Err(err)
　　},
　}
}

>>613
その通り
?オペレータは、ResultがErr(err)の時にreturn Err(err);する。
正確には便利に変換してくれるreturn Err(From::from(err));だが本筋でないので略。

**デフォルトの名無しさん** · 2022/01/13(木) 17:01:12.46

>>615
> ?オペレータは、ResultがErr(err)の時にreturn Err(err);する。

なるほど、勉強になった
ただ、前述したとおり、書き捨てのプログラムでない限りエラーが発生したときには詳細なエラーログを出力する必要もあるし、Rustの常識が多言語でもベストプラクティスとはならないと思うよ

**デフォルトの名無しさん** · 2022/01/13(木) 17:09:11.61

>>611
googleに聞いてくれ
https://ttsuki.github.io/styleguide/cppguide.ja.html#Exceptions

**デフォルトの名無しさん** · 2022/01/13(木) 17:24:20.34

>>614
スタックトレースまで必要になるならば、それはエラーではなくプログラムのバグだろう。
その区別を付けたほうが好ましい。
そして、エラーではなくバグならば前述したようにpanicの対象なのでpanicさせることもできる。

>>616
Resultの正常値もエラー値も任意の情報を持たせられるので必要な時に必要な処理をすれば困ることはない。

>>617
そのGoogleのC++スタイルガイドに「C++の例外は使いません。」と明記されているのか。
これはGoogleが正しい。
もちろん、Googleが作ったGo言語に例外はない。
プログラミングにおいてtry catchの例外機構は不要である。

**デフォルトの名無しさん** · 2022/01/13(木) 17:55:38.36

try/catchよりもRustの方法が良い点としては
let val = foo()?;　とした時に
正常値valの時だけに専念できるだけでなく
foo()はエラーを返すこともあってその処理は上位に委譲していますよ！と
?オペレーターの存在で明瞭になる点

これは裏返せばtry/catch例外方式の致命的な欠点
どこで誰が例外を返すのかわからなかったり
多段呼び出しの途中の関数では例外が通過するのかどうか全てを追わないとわからなかったり
プログラミングにおいて例外は悪だと思う
グーグルはちゃんとわかっている

**デフォルトの名無しさん** · 2022/01/13(木) 18:12:05.30

>>618
> スタックトレースまで必要になるならば、それはエラーではなくプログラムのバグだろう。

エラーが発生した場所がどこであるのかが例外オブジェクトに含まれているなら、スタックトレースが不要な場合もあるかもしれませんが、あればどういう呼び出しのときにエラーが発生したのかわかるので便利です

> その区別を付けたほうが好ましい。

大抵の場合は例外の種別や例外オブジェクトの継承ツリーで区別をつけてると思います
LogicExeptionを継承する例外ととRuntimeExceptionを継承する例外とか

> >>617
> そのGoogleのC++スタイルガイドに「C++の例外は使いません。」と明記されているのか。
> これはGoogleが正しい。

Googleがそうやっているだけで、それがベストプラクティスとは限りません
>>611 のコードにエラーログ出力を追加しようとしたらひと苦労です

**デフォルトの名無しさん** · 2022/01/13(木) 18:20:01.16

Googleのスタイルガイドでは、C++の例外は雑に扱えないぐらいには面倒だしメリットがそこまで大きくもない、って書いてるぐらいで、例外は不要だとは断じてないよね

面倒だからGoogleの巨大なレガシーコードには今更例外を導入できないし、それが依存する可能性のあるプロジェクトにも例外は使わせたくない、って感じでしょ

**デフォルトの名無しさん** · 2022/01/13(木) 18:27:00.76

>>620 >>621
だからこそGoogleもMicrosoftもAmazonもFacebookも一緒になって共同でRust Foundationを設立。
それぞれ新規のものや既存のものの改善などを機会に、Rustへの移行を着実に進めている。
既存の枯れたものまで一気に置き換えるという無駄なことはしないが、今後もC++が使われ続けるのはそれだけになる。

**デフォルトの名無しさん** · 2022/01/13(木) 18:31:49.09

>>622
話がずれていってるけど、大本の話題はこれだからね

> プログラミングにおいて、エラー処理のためのtry catch例外処理は本来不要なものである。
> エラーは関数の戻り値で返せばよい。

あと、軽く調べたが、googleはSTLもboostも基本使えないみたいよ
もちろん、例外をthrowするサードパーティ製ライブラリも使えない
修行僧みたいw

**デフォルトの名無しさん** · 2022/01/13(木) 18:33:20.28

あと、Microsoftは違うスタンスみたいだよ

https://docs.microsoft.com/ja-jp/cpp/cpp/errors-and-exception-handling-modern-cpp?view=msvc-170

> 最新の C++ のほとんどのシナリオでは、論理エラーとランタイムエラーの両方を報告および処理する方法として、例外を使用することが推奨されます。特に、エラーを検出する関数と、エラーを処理するコンテキストを持つ関数の間に複数の関数呼び出しがスタックに含まれている可能性がある場合に当てはまるとします。例外は、エラーを検出して情報を呼び出し履歴に渡すコードに関する、正しく定義された正式な方法を提供します。

**デフォルトの名無しさん** · 2022/01/13(木) 18:52:55.65

>>624
なるほど
プログラムのバグとエラー(＝入出力や相手次第で発生)の両方を、ごっちゃに同じ例外で扱ってる自覚はあるわけだ。
>>615のRustのように書ければ例外を使わずともエラーを綺麗に明瞭に処理できるのだが、
C++では言語の機能不足のため、修行僧モードになるか例外を使うかの二択なのだろう。
いずれにせよMicrosoftもRustに積極的だから、時間をかけて脱C++へ進んでいることに変わりはない。

**デフォルトの名無しさん** · 2022/01/13(木) 19:13:49.01

>>625
> プログラムのバグとエラー(＝入出力や相手次第で発生)の両方を、ごっちゃに同じ例外で扱ってる自覚はあるわけだ。

そもそも、アプリケーションプログラマバグによる例外のthrowはほぼ書かないと思いますけどね
バグ由来の「異常発生」には、ほぼ誰も気にしてないと思うよ（もちろん、最終的な処理が必要なら書くけど）

> いずれにせよMicrosoftもRustに積極的だから、時間をかけて脱C++へ進んでいることに変わりはない。

多分、30年は無理じゃないかな（個人の感想です）
Java, C++がでてきてからもう30年くらい？かな
COBOLやFORTRANの生き残り具合を鑑みるとそう思えます

https://www.tiobe.com/tiobe-index/
Fortran 19位
COBOL 25位
Rust 26位　← 思ったより検討してた

**デフォルトの名無しさん** · 2022/01/13(木) 19:25:42.66

Rustの利点はわかったけど、?演算子とpanicは例外の発展形にしか見えないなぁ。
(?演算子でエラー移譲を受けた)呼び出し元は、エラーを無視してもpanicしなくて済むのかしらん？
エラーを処理しなきゃいけないんだったら例外と大して変わらん気がする。

**デフォルトの名無しさん** · 2022/01/13(木) 19:47:20.65

例外は危険。
使うべからず。

**デフォルトの名無しさん** · 2022/01/13(木) 19:47:53.64

>>626
単なる通信エラーにすぎなくてもtry catchの例外で受ける例はあるよね。
>>606のデータベースアクセスの例だと、DBサーバーとの通信時エラーが起きるとfoo()は例外を投げることになる。
しかも例外を投げるのはfoo()自身ではなく、そこから呼ぶDBサーバ通信部分だったり、そこから呼ぶ汎用通信ライブラリだったり、誰が例外を投げるかわからない。

>>627
今書いている関数で例外が発生するのかどうか、奥底まで追わないとはっきりしないデメリットが例外にはある。
?演算子を使えば、下からエラーが来ていて上へエラー処理を移譲していることが明確になる。
あと、質問に対する答えは、main()関数までもがさぼってResultを返せば、自分でエラー処理をせずともエラー表示される。

**デフォルトの名無しさん** · 2022/01/13(木) 20:16:47.27

>>629
実際にはこないのに来るかもしれないと思わせるだけかもしれないだろ
それならtry catchだって来ると思っとけばよい

**デフォルトの名無しさん** · 2022/01/13(木) 21:01:12.03

>>627
エラー処理はそんな大変なことではなく例えば
if let Ok(value) = foo() {
　bar(value);
}
と正常値の時だけ処理したりも出来る
正常値を得るにはif letやmatchやその他にResult型のメソッドなどを必ず使わないと正常値を取り出せないので
Rustではエラー値なのにチェック忘れで突き進むバグが生じないのも利点

**デフォルトの名無しさん** · 2022/01/13(木) 21:59:08.34

Rust全くわかってないんだけどOkはマクロ？

**デフォルトの名無しさん** · 2022/01/13(木) 22:10:33.52

>>632
EnumであるResult型がとりうる値の種類
パターンマッチさせてResultの中身がOkの場合だけ条件が真になる

**デフォルトの名無しさん** · 2022/01/13(木) 22:14:53.71

>>627
メリットでもデメリットでもあるが例外との一番の違いは
関数の型でどういうエラーが発生するのかしないのか分かるという点

**デフォルトの名無しさん** · 2022/01/13(木) 22:26:16.24

>>570
>大半のアプリケーションでは個別にハンドリングせず
>集約エラーハンドラに任せたいとエラーのほうが圧倒的多数だから

どこでなぜ起きたかわからないエラーをキャッチしてもなぁ。
erlangのlet it crashのようにエラーの種類は考慮しないってんならわからんでもないけど。

**デフォルトの名無しさん** · 2022/01/13(木) 22:36:17.73

>>632
Okはenumの識別子。
Result型はenumでありOk(正常値)とErr(エラー値)のどちらかになる。
enumといってもRustは識別子に付随する値を持つこともできる。
つまりC/C++には無い新たな枠組みで、これがRustを強力にしている一つ。

>>630
try catchは関数呼び出しが多段になった時に、
途中の関数ではtry catchもthrowも出てこないから情報がなく気付けない。
Rustは途中の関数で?オペレータを必ず付けるから、
エラーが起きる可能性があることを必ず認識できる。

>>631
Resultに対して多数のメソッドがあって短くエラー処理できる点もいいね。
例えば以下の2つは同じで、エラー時にDEFAULT_VALUEとなる。
let a = foo().unwrap_or(DEFAULT_VALUE);
let a = if let Ok(value) = foo() { value } else { DEFAULT_VALUE };

以下の2つも同じで、エラー時にクロージャ |err| bar(err) の値となる。
let b = foo().unwrap_or_else(|err| bar(err));
let b = match foo() {
　Ok(value) => value,
　Err(err) => |err| bar(err),
};

**デフォルトの名無しさん** · 2022/01/13(木) 22:40:25.51

>>588
bad_allocは絶対発生しないシステムなの？

**デフォルトの名無しさん** · 2022/01/13(木) 22:56:39.62

>>635
集約エラーハンドラは汎用のエラー画面表示やログ出力のためだぞ
例外の中身を見ればどこでなぜ起きたかはわかるがユーザーには対処できないものを扱う
Erlangは軽量プロセス単位のリトライなので全然違う

**デフォルトの名無しさん** · 2022/01/13(木) 23:29:52.77

>集約エラーハンドラは汎用のエラー画面表示やログ出力のためだぞ

例外マンセー軍全員こう思ってる？
参ったw

**デフォルトの名無しさん** · 2022/01/14(金) 00:04:27.93

>>631
戻り値無し（副作用目的）で失敗する可能性のある関数もチェック忘れ防げるようになってたっけ？

**デフォルトの名無しさん** · 2022/01/14(金) 00:14:04.94

例外が嫌いすぎて例外使ったことないエアプだから、頓珍漢なことしか言えない
議論する価値ないわ

**デフォルトの名無しさん** · 2022/01/14(金) 00:14:49.01

>>640
正常系の戻り値がない関数なら戻り値はResult<(),Error>になって、これを無視するとwarningが出るから気付く

**デフォルトの名無しさん** · 2022/01/14(金) 00:19:25.76

>>640
まず関数の戻り型はResult<(), Error>となる
()はRustで戻り値なしを意味しタプル0個と覚えれる
次にその関数を普通にfoo();と呼び出すコードを書く
すると「使われていないResult値がある」とコンパイラに警告される
したがってエラー値チェックを忘れていることに気付ける

**デフォルトの名無しさん** · 2022/01/14(金) 00:20:04.51

>>642
おー、ほんとだ。いいね。
https://doc.rust-lang.org/src/core/result.rs.html#71-75
> //! A common problem with using return values to indicate errors is
> //! that it is easy to ignore the return value, thus failing to handle
> //! the error. [`Result`] is annotated with the `#[must_use]` attribute,
> //! which will cause the compiler to issue a warning when a Result
> //! value is ignored. ...

**デフォルトの名無しさん** · 2022/01/14(金) 13:50:52.20

>>629
> 今書いている関数で例外が発生するのかどうか、奥底まで追わないとはっきりしないデメリットが例外にはある。

今書いている関数では、ハンドリングする例外に着目するだけでいいんだが
（何を言ってるのかわからんかもしれんが）

**デフォルトの名無しさん** · 2022/01/14(金) 13:52:22.52

>>639
> 参ったw

何が参ったなのかわからんが、例外オブジェクトがエラーの情報を持っているから汎用処理にできるんだが

**デフォルトの名無しさん** · 2022/01/14(金) 13:55:14.01

Googleのコーディング規約が神だと思ってるみたいだが、発表された当時内容があまりにアレだったので界隈がざわついた記憶がある
組み込み関連は知らんが、それ以外でGoogleのコーディング規約を取り入れてるところはないんじゃないか

**デフォルトの名無しさん** · 2022/01/14(金) 14:37:16.30

参考にしてるのは業務でまともにC++を使ったことがない素人ばかりかもね

**デフォルトの名無しさん** · 2022/01/14(金) 14:45:16.44

>>629
> 今書いている関数で例外が発生するのかどうか、奥底まで追わないとはっきりしないデメリットが例外にはある。
逆にRustだとなんかの理由で奥底の関数がエラーを返すように変更されたらその上の関数全てを変更するってこと？

**デフォルトの名無しさん** · 2022/01/14(金) 15:08:09.78

Rust始めたばかりだからまだよくわかってないが、エラー処理周りのこと調べると、まだまだ迷走中な感じだな
少なくとも初手から言語仕様として完璧なエラー処理構造が入ってたわけではないことがわかった

Rust のエラーまわりの変遷
https://qiita.com/legokichi/items/d4819f7d464c0d2ce2b8

**デフォルトの名無しさん** · 2022/01/14(金) 15:14:13.63

>>649
まず一般的にどの言語であっても奥底の関数の仕様が変更されたらそれを吸収できるところは変更となる
次にエラーが起きない関数が突然にエラーが起きるようにはならないのでそんな仕様変更は起きない
入出力相手があるものは初めからエラーが起きうることがわかるしメモリ上の操作だけであってもsearchやmatchなど成否が起きうるものも最初からわかっている

**デフォルトの名無しさん** · 2022/01/14(金) 15:21:48.16

「そんな仕様変更は起きない」ということはなく、普通にAPIの設計ミスっててやっぱりエラーになる可能性あった、というのはありうる
その場合Rustならコンパイルエラーで気付くが、例外だとこれまで例外出さなかった関数が急に出すようになるわけで、なかなか厳しいね

**デフォルトの名無しさん** · 2022/01/14(金) 15:24:49.44

>>651
> まず一般的にどの言語であっても奥底の関数の仕様が変更されたらそれを吸収できるところは変更となる
例外なら途中の関数の変更は不要だよ

> 次にエラーが起きない関数が突然にエラーが起きるようにはならないのでそんな仕様変更は起きない
お前さんの妄想は要らんよ

> 入出力相手があるものは初めからエラーが起きうることがわかるしメモリ上の操作だけであってもsearchやmatchなど成否が起きうるものも最初からわかっている
計算だけしかしない関数が外部に計算させるように変更されたらどうするの？

**デフォルトの名無しさん** · 2022/01/14(金) 15:28:08.59

>>652
> 例外だとこれまで例外出さなかった関数が急に出すようになるわけで、なかなか厳しいね
例外出すように変更したら当然それを受けるように変更するでしょ？
例外なら発生と受けるところの変更だけで済むけど、Rustだと間の関数も全て変更が必要じゃね？

**デフォルトの名無しさん** · 2022/01/14(金) 15:34:01.30

try-catchは素人にはうまく使えないよなあ、とは思う

**デフォルトの名無しさん** · 2022/01/14(金) 15:36:58.27

てかエラー処理全般、本気でやるとしたら世の中でできるやつはかなり限られてる。
GAFAとか含めてもそう。

**デフォルトの名無しさん** · 2022/01/14(金) 15:37:15.18

>>654
自分で変更したとしても、それを使っている箇所を漏れなく変更できるか？という問題もあるし
ましてや依存ライブラリの仕様変更だったらどうするの？という話
誰もがCHANGELOGを正しく書いてくれるわけではないし、見落としだってある

**デフォルトの名無しさん** · 2022/01/14(金) 15:44:57.54

>>654
途中で低位層の仕様が変わるとか有り得ない机上の空論に対して
どこまで何を前提にしていいのか何もかも不明だから誰も何も答えられない

**デフォルトの名無しさん** · 2022/01/14(金) 15:51:24.55

>>657
ああRustだと全部変更必要だけどサボるとコンパイルエラーになるってことか、了解
コールツリー作れれば例外でもチェックできそうな気もする

>>658
>>652 とか俺も例まで書いてあるのに理解できないアリエナイ君は出てこない方が良いかとw

> 計算だけしかしない関数が外部に計算させるように変更されたらどうするの？

**デフォルトの名無しさん** · 2022/01/14(金) 16:03:30.57

>>659
まぁ変更が面倒というのは全くその通り
個人的にはコーナーケースのデバッグコストを事前に払ってるだけだから面倒よりありがたいって思ってるけど、嫌いな人はいるだろうね

**デフォルトの名無しさん** · 2022/01/14(金) 16:16:10.98

面倒というより本質的に途中の関数には関係ないはずなのに修正が必要になると言うのがちょっと嫌かな
まあ現状ではmore betterなんだろうけどなんとか洗練されないものかと

**デフォルトの名無しさん** · 2022/01/14(金) 16:27:26.86

>>659
外部サーバーに計算させるよう変更するには
まずその外部のIPアドレスかホスト名かそれらを含むURIなどが新たなパラメタとして引数に入る
途中の関数があるとすれば全て影響を受けるだろう

さらにそのようなことが必要な規模の計算の場合
外部サーバーを使わずとも自分のところでも並列計算をしていたはずである
また計算以外も含めて今どきはマルチスレッド利用が前提とすると
スレッド間の例外は不可もしくは例外を使わず受け渡しをして投げ直すことになる
結局これは例外を使わない場合と同じことをせざるをえなくなる

**デフォルトの名無しさん** · 2022/01/14(金) 16:39:58.04

>>662
> まずその外部のIPアドレスかホスト名かそれらを含むURIなどが新たなパラメタとして引数に入る
クラスとか使ったことないのかな？

> 外部サーバーを使わずとも自分のところでも並列計算をしていたはずである
はずはず君w
もう少し考えてからレスしないと恥の上塗りにしかなってないよ

**デフォルトの名無しさん** · 2022/01/14(金) 16:45:29.34

>>662
計算じゃなく、データベースにクエリー投げるとか普通にあるだろ。　そういう場合、
いちいち関数の引数にIPアドレスやホスト名を渡すのではなく、オブジェクトメンバ
として持たせて、計算メソッドを呼ぶって実装にするのでは？

んで、サーバー応答がない場合だけでなく、IPアドレスやホスト名をセットせずに、
計算メソッドを呼んだりしたら、例外を投げるよな？

**デフォルトの名無しさん** · 2022/01/14(金) 16:46:26.60

>>658
> 途中で低位層の仕様が変わるとか有り得ない机上の空論に対して
> どこまで何を前提にしていいのか何もかも不明だから誰も何も答えられない

やっぱり例外のことわかってないね
自作関数hoge()がサードパーティ製ライブラリの関数foo()を呼び出しているとき、hoge()ではfoo()が送出する例外をどうするかを実装するだけでいい
その後、foo()が更新されfoo()が依存するライブラリが例えばIoErrorをthrowするようになってfoo()はそれに対して何もしないとしても、hoge()は変更する必要がないし知る必要もない

**デフォルトの名無しさん** · 2022/01/14(金) 16:48:22.67

並行並列処理した時点で例外が破綻するのは事実だな
擬似的に例外を伝播させるにしても途中でエラー値渡しが必要
例外を使えば途中は何も考えなくていいはウソだな

**デフォルトの名無しさん** · 2022/01/14(金) 16:55:06.25

そもそも、例えばJavaScriptでnpmパッケージを少しつかうと、数百個のnpmパッケージがインストールされて数千個のthrowが実装されてて、全貌を知るなんて無理んだんだよ
そんなこと知らなくても、JavaScriptでアプリコードは書ける

**デフォルトの名無しさん** · 2022/01/14(金) 16:56:04.83

>>666
スレッド内では関数を多段に呼び出すことはないという主張なのかな？

**デフォルトの名無しさん** · 2022/01/14(金) 16:57:10.80

やっぱこいつ例外のことなんもわかってねーわ

**デフォルトの名無しさん** · 2022/01/14(金) 16:59:50.72

>>663 >>664
計算を与えるものと
サーバー情報を与えるものは
明らかに独立して扱うべきもの
内部で計算するなら前者だけで済む
なるべく依存関係を少なくモノリシックにならないように設計するのが常識

>>664
ホスト名がないとかサーバーが応答しないとか
そんな普通に起こりうることはエラーを返す

**デフォルトの名無しさん** · 2022/01/14(金) 17:02:36.16

>>665
知らなくていいメリットか知りようがないデメリットか

**デフォルトの名無しさん** · 2022/01/14(金) 17:02:40.51

>>668
並列計算スレッドの中で多段に呼ぶのはいいが何をしたいんだ？
ちゃんと頭の中が整理できていないだろw
コードを書いたことあるのかね？

**デフォルトの名無しさん** · 2022/01/14(金) 17:03:04.21

例外がわかってないっつーか
プログラミングど素人だったわw

**デフォルトの名無しさん** · 2022/01/14(金) 17:10:08.74

>>654
そうだよ
Tで返してたところをOption<T>で返すように変更が入るとかは普通にある

型で表現できることのメリットの裏返しで
型で表現してるからこそそれに依存してるところは全部変更が必要
誰か書いてたけど検査例外と同じデメリットがある

**デフォルトの名無しさん** · 2022/01/14(金) 17:13:19.40

>>665
これはRustでも同じ
hoge()ではfoo()が返すResult<T, E>のErrorだけ気にすればいいように作る
(正確にはfooを含むmod Fooが定義するErrorのうちfooが返すものだけ気にする)

**デフォルトの名無しさん** · 2022/01/14(金) 17:13:47.97

>>665
JavaScriptについてちゃんとわかっていないようだな
それらは大量にあっても自分のところに飛んで来ないthrowだ
自分のところに飛んでくるthrowはcatchしないとuncaughtExceptionで怒られる
だから下から例外が来るか否かは把握していないといけない
そもそも途中でライブラリの仕様が変わって例外を投げるようになること自体がナンセンスだが

**デフォルトの名無しさん** · 2022/01/14(金) 17:26:27.30

>>667
まずは例外の基本を理解しなさい
ライブラリ群のソースの中に何千個のthrowがあろうが各々のtry-catchで閉じ込められておりその外に対しては一切無関係
関係があるのは自分に向かって来る分のみ

**デフォルトの名無しさん** · 2022/01/14(金) 17:43:36.82

>>670
> 明らかに独立して扱うべきもの
機能が一緒なのに？
君のべき論ならそうなのかも知れないけど、それが一般的というわけではないよね

**デフォルトの名無しさん** · 2022/01/14(金) 17:45:12.30

>>672
整理できてないのはお・ま・え w

**デフォルトの名無しさん** · 2022/01/14(金) 17:48:13.03

>>674
そこは了解
まあ単純に上位に渡すだけならIDEで自動で修正とかできそう

**デフォルトの名無しさん** · 2022/01/14(金) 18:00:55.12

>>679
じゃあ並列計算スレッドの中で多段に呼ぶ関数があるとして
どういう仕様変更をせざるをえなくなるのか具体的に答えてみよ
無いと思うけどな

**デフォルトの名無しさん** · 2022/01/14(金) 19:16:22.53

そもそもrustで言うと Result<T, E> の E を変更するのは破壊的変更だから普通は依存crateのエラー型をそのまま外部に見せるようなことはしない

**デフォルトの名無しさん** · 2022/01/14(金) 19:42:59.80

>>681
スレッド内ではシングルスレッドと同じだろ
スレ読み直してこい

**デフォルトの名無しさん** · 2022/01/14(金) 19:49:44.98

>>683
で、並列計算スレッドの中で多段に呼ぶ関数があるとして
具体的にどういう仕様変更をせざるをえなくなるのか早く答えて欲しい
無いと思うけどな

**デフォルトの名無しさん** · 2022/01/14(金) 20:30:51.27

コードの修正が必要になるって話な

> 逆にRustだとなんかの理由で奥底の関数がエラーを返すように変更されたらその上の関数全てを変更するってこと？

**デフォルトの名無しさん** · 2022/01/14(金) 20:46:13.89

>>685
エラーに限らず一般的によくあることだね
返すべき値が増えたり
返すべき型が変わったり
あるいは逆に
引き渡す値が増えたり
引き渡す型が変わったり
それらは機能追加変更でも起きるけど
リファクタリングでも起きたりしてる
Rustでも他の言語でもその状況は変わらない

**デフォルトの名無しさん** · 2022/01/14(金) 21:26:13.10

話の流れ見えてる？

> 例外なら発生と受けるところの変更だけで済むけど、Rustだと間の関数も全て変更が必要じゃね？

> 面倒というより本質的に途中の関数には関係ないはずなのに修正が必要になると言うのがちょっと嫌かな

**デフォルトの名無しさん** · 2022/01/14(金) 21:29:54.99

>>686
それがコールツリーを遡って何層にも伝播していくのは普通にある事ではない
あるなら設計が悪い

**デフォルトの名無しさん** · 2022/01/14(金) 21:33:39.15

どこでどういう例外が発生するか全部把握している人にとっては造作もないこと

**デフォルトの名無しさん** · 2022/01/14(金) 21:40:25.58

>>687
Rustでも下位でエラー(例外)の種類が増えたとしたら
同じように上位の関数でそれらのエラーを処理する場合
?オペレーターで飛ばす途中の関数はそのまま変更ないよ

**デフォルトの名無しさん** · 2022/01/14(金) 21:52:56.30

>>690
少し上のレスくらいは読んでくれ…

> 逆にRustだとなんかの理由で奥底の関数がエラーを返すように変更されたらその上の関数全てを変更するってこと？

**デフォルトの名無しさん** · 2022/01/14(金) 22:00:42.61

>?オペレーターで飛ばす途中の関数はそのまま変更ないよ

?オペレーターかどうかは関係ないやろ
いつもいつもホントいい加減な事言うよなぁ

**デフォルトの名無しさん** · 2022/01/14(金) 22:16:08.15

>>691
その関数の元の戻り型と変更後の戻り型次第じゃないかな
元々がそのエラーと別の他のエラーを返しているか何らかの理由でResultならば
既にその関数呼び出しに?オペレーターを付けてあるので変更なし
その関数の元の戻り型が新たにResultになったのならば
その関数呼び出しに?オペレーターを付ける
それに応じて自分自身に対しても以下同様

>>692
間違ったことは言っていないつもりだが
もし何かミスがあれば指摘くれるとうれしい
もうそろそろ寝室へ移動するが

**デフォルトの名無しさん** · 2022/01/14(金) 22:28:31.33

検査例外の不便さを軽減しつつ例外が送出されることのみ型で明記する方式をとったのがSwift
RustのResultを返す方式と基本思想は同じだがエラーの型を明記しなくていいので使いやすい

**デフォルトの名無しさん** · 2022/01/14(金) 22:32:28.06

エラーの種類を型で区別するというのがそもそも無理があったんだろうな。

**デフォルトの名無しさん** · 2022/01/14(金) 22:35:46.65

>>694
エラーの型の明記自体は必要なことだから問題ないんじゃないかな
>>695
もちろんRustではdyn Errorで何でも楽する形から個別に用意して堅牢にする方法まで様々な形態を取ることができる

**デフォルトの名無しさん** · 2022/01/14(金) 22:45:19.38

>>693
> その関数呼び出しに?オペレーターを付ける
> それに応じて自分自身に対しても以下同様
だからそれが必要だろって話
てか、話がループしてるからはよ寝ろ

**デフォルトの名無しさん** · 2022/01/14(金) 22:53:53.91

>>697
型が変わるケースのみ最小限の限定した対応が必要となるのは当たり前
そんな常識を「必要だろ」とわざわざ言われても…
おやすみ

**デフォルトの名無しさん** · 2022/01/15(土) 00:46:19.46

言語が違うんだからやり方や考え方が違うというのはべつにどうでもよくて
どちらの方がバグを生みにくいのかが気になる
エラーハンドリングにまつわるバグもいろいろあるけど、例えばリカバリ可能なエラーを取り逃してプログラムがクラッシュする可能性が低いのはどっちなの？

**デフォルトの名無しさん** · 2022/01/15(土) 02:37:29.52

メモリがないとパニックしてabortってなんなの？
動作変えられないの？

**デフォルトの名無しさん** · 2022/01/15(土) 02:40:42.88

>>699
それならばRustが安全
Rustのenum Result型から正常値を取り出すには
matchやif letもしくはResult型のメソッドunwrap_*()などの
エラー値ではない時のみ正常値を取り出し使える手段を必ず経る必要がある
つまり正常値を使って処理していくコードはエラー値ではない時だけしか動作しないことが保証される

**デフォルトの名無しさん** · 2022/01/15(土) 08:12:31.52

>>698
常識と言いながら話をループさせるのはもしかして認知症… w

**デフォルトの名無しさん** · 2022/01/15(土) 08:49:08.65

>>701エラーケースのリカバリの話をしているんだが

**デフォルトの名無しさん** · 2022/01/15(土) 09:29:13.90

>>701
例外でも保証されるじゃん
何言ってんの

**デフォルトの名無しさん** · 2022/01/15(土) 09:44:44.45

ここはrustをよく知らない人に
rust初心者がrustをゴリ押しするスレです。

**デフォルトの名無しさん** · 2022/01/15(土) 09:46:20.74

>>699
強いて言えばRustかな

**デフォルトの名無しさん** · 2022/01/15(土) 10:05:00.72

できるだけコンパイル時にチェックしてくれるほうが良い。

**デフォルトの名無しさん** · 2022/01/15(土) 10:09:23.43

>>699
JavaやSwiftみたいに検査例外があるやつはRustと大差ないだろうね
非検査例外しかないやつだとcatch忘れるのを防げないが
あとはfinallyやdeferによるエラー時の後始末は忘れる可能性があるが、RustならRAIIに任せられる範囲内でなら忘れない

**デフォルトの名無しさん** · 2022/01/15(土) 10:10:14.51

日本語初心者でもありそう