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/10(月) 02:26:23.03

>>541
それは単なるリソース不足による数値の溢れだから無意味
例えば>>538のプログラムはi32型をi64型やi128型やu128型にすれば少しは延命する
例えばu128型(unsigned 128bit整数)にすれば185個の正しいフィボナッチ数列を出力できる
しかしそこまでに過ぎずこれはリソース不足の問題である
それより上はBigIntなどの数値上の上限がない型を用いることになる
するとこれもいずれ途中でメモリ不足でアロケーションできず同様にpanicするだろう
したがってこれは「プログラムの論理的な間違い」ではなく「数値の溢れというリソース不足の問題」である

**デフォルトの名無しさん** · 2022/01/10(月) 02:32:35.04

>>541
論理的に返答できる相手がどうかも論理的に考慮してくださいよ

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

例外は危険なりよ。

**デフォルトの名無しさん** · 2022/01/10(月) 08:11:22.08

有限回のイテレーションしか回せないことが分かっているのに無限ループで書くのはプログラムの論理的な誤りじゃないんだ？
メモリだのファイルディスクリプタだのPIDだのの枯渇、いわゆる通常の「リソース不足」と違って、事前に発生が完全に予見できるのに？

**デフォルトの名無しさん** · 2022/01/10(月) 08:38:15.28

一般的に対策としてはもっと大きな整数が扱える型を用いることになり行き着く先はBigInt
例えば以下のフィボナッチ数列を表示するプログラム
論理的な誤りがあると主張するならば具体的にどこをどう直しますか？
use num_bigint::BigInt;
fn main() {
let mut m: BigInt = 1.into();
let mut n: BigInt = 1.into();
loop {
println!("{}", m);
let next = m + n.clone();
m = n;
n = next;
}
}

**デフォルトの名無しさん** · 2022/01/10(月) 08:43:23.03

>>538
普通は必要とされる範囲を規定してそれに適した型を使う
なのでオーバーフローは論理ミスだよ

**デフォルトの名無しさん** · 2022/01/10(月) 08:50:28.54

>>546
しれっとBigIntに直したそのプログラムには論理的な誤りがあると主張しません
>>538のi32版は論理的な誤りがあり、+の代わりにchecked_addを使って以下のように修正できます
fn main() {
let mut m: i32 = 1;
let mut n: i32 = 1;
loop {
println!("{}", m);
if let Some(next) = m.checked_add(n) {
m = n;
n = next;
} else {
break;
}
}
}
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2021&gist=17058fd1c2a1c69f111ac09a94681ee6

**デフォルトの名無しさん** · 2022/01/10(月) 08:56:07.29

>>545
有限回のイテレーションしか回せないとしてもその回数を事前に知るのは困難ではないか？
だから無限ループを用いるとこには何ら問題ないと思う

>>547
範囲を規定できる用途ばかりではないだろう
そのケースは出来る限り多くのフィボナッチ数を出力したいのだから範囲を規定することがナンセンス

**デフォルトの名無しさん** · 2022/01/10(月) 08:57:32.63

>>548
それは>>196で既出

**デフォルトの名無しさん** · 2022/01/10(月) 09:03:32.42

>>548
それは>>532の「このうち数値溢れ演算はpanicを起さないチェック付き演算で置き換えて回避可能」の通りだから当たり前

**デフォルトの名無しさん** · 2022/01/10(月) 09:03:49.79

>>549
> 範囲を規定できる用途ばかりではないだろう
規定できる用途の方がはるかに多い
て言うかまともなプログラムなら規定してないなんてことはまずない
テストできないし
> そのケースは出来る限り多くのフィボナッチ数を出力したいのだから範囲を規定することがナンセンス
そんなケース滅多にないだろw

**デフォルトの名無しさん** · 2022/01/10(月) 09:07:37.24

>>551
「チェック付き演算に置き換えて回避可能」は「本質的にリカバリできない」に含まれるのか？

ていうかそもそもその区分は何のために存在するんだ？
Rustが例外を採用しない理由として言語開発者たちがそのように主張しているのか？
それとも君の感想？

**デフォルトの名無しさん** · 2022/01/10(月) 09:20:25.60

>>553
前者はpanicを回避可能
それでも計算続行不可能という点では後者の本質的にリカバリできないに該当なのかな
だからそれらは両立していると思うのだがどうだろうか？

あと「例外を採用しない理由」をなぜここで突然言及するのか疑問だが
もし以下の話について言っているのならば
>>532
>> Rustがtry-catchの例外機構を持たない理由は非常に単純で
>> (A) 本質的にリカバリできることは通常のエラー処理だけで十分に対処可
>> (B) 本質的にリカバリできないことはpanic

チェック付き演算を使用した場合は前者になるし
使用せずにオーバーフローすれば後者になるのだから
そこに何か明白でない論点はないと思うのだがどうだろうか？

**デフォルトの名無しさん** · 2022/01/10(月) 09:31:36.48

>>546
それリソース不足にはなるけどオーバーフローにはならないよね？

**デフォルトの名無しさん** · 2022/01/10(月) 09:44:54.40

>>552
ケースが多いか少ないかは関係ない
ケースが少ないから無視していいなんてことはプログラミング界隈ではありえない

>>555
元々こう書かれてるからそこはどちらでも関係ないかもな
多倍長整数型が溢れるのはリソース不足しか思いつかん

＞　>>532
＞　- 数値型が溢れて計算を続行できない場合

**デフォルトの名無しさん** · 2022/01/10(月) 11:51:44.97

今日はNGしやすくて助かる
いつもこの調子で頼むよ

**デフォルトの名無しさん** · 2022/01/10(月) 12:01:05.13

>>553
リカバリできないかどうかは状況に応じて開発者が主観的に判断するものなので
「本質的にリカバリできない」かどうかを考えるのは無意味

エラーハンドリングの基本
もちろんRustの言語開発者も同じ考え方
https://doc.rust-lang.org/book/ch09-03-to-panic-or-not-to-panic.html

**デフォルトの名無しさん** · 2022/01/10(月) 12:12:45.84

Rustはそこに書いてあるようにエラーをResultで返すかpanicかの2択で済むもんな

**デフォルトの名無しさん** · 2022/01/10(月) 13:03:25.90

>>556
>> - 数値型が溢れて計算を続行できない場合
だからそれは論理間違いだろ

**デフォルトの名無しさん** · 2022/01/10(月) 13:56:51.54

数値型のオーバーフローをリソース不足と言って共感得るのは無理だろうな
プログラムにおける上限下限は暗黙的または経験則的に考慮して設計実装されるし、まともなユニットテスト書けば当然検出されるバグ

仮にオープンソースとして世に出すなら、マニュアルやバグレポートに対してどう対処するのか興味ある

**デフォルトの名無しさん** · 2022/01/10(月) 14:09:36.74

曖昧な例外を廃して、とかいっても結局そういう「経験的」とかいう曖昧なレベルでしかなされてないってことよな

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

本人の理解が曖昧なだけだから

**デフォルトの名無しさん** · 2022/01/11(火) 15:22:08.76

結局try catch例外処理なんて最初から不要なものだったんだな
だから最近の言語RustやGoにはそのような無駄なものがないわけだ

**デフォルトの名無しさん** · 2022/01/11(火) 15:51:54.57

Rustが例外機構を無くとも同等のことを快適に記述できる要因は二つ
HaskellのEitherモナドを値付きenumとして表現したResult<T,E>を関数の戻り型としたこと
そしてResultがErrの時に?オペレーターにより見えない即時returnをするショートカットを用意したこと

**デフォルトの名無しさん** · 2022/01/11(火) 16:40:23.19

気持ち悪い自演はもうやめてーー

**デフォルトの名無しさん** · 2022/01/11(火) 21:12:28.05

検査例外と一緒なんだけどね

**デフォルトの名無しさん** · 2022/01/11(火) 21:26:17.78

そういえば例外の信奉者ほどJavaの検査例外を糞味噌に言うけど、例外機構の型検査をきっちりやろうとしたら
ああいう方法しかないわけだよね。

**デフォルトの名無しさん** · 2022/01/11(火) 23:24:53.53

フロントエンドやサーバーサイドは間欠故障まではあっても、大抵リトライとタイムアウトで救える
バックエンドの耐障害性の設計がまともなら、だけど

そりゃエラーチェックなんて馬鹿らしくなるわな

**デフォルトの名無しさん** · 2022/01/11(火) 23:38:16.29

大半のアプリケーションでは個別にハンドリングせず
集約エラーハンドラに任せたいとエラーのほうが圧倒的多数だから
呼び出し階層全てにどの例外が発生しうるかを書いていかないといけない検査例外が嫌われるのは自然なこと

Javaの場合は例外クラスの階層の問題とかその他の要素も相まって糞味噌扱い

**デフォルトの名無しさん** · 2022/01/11(火) 23:39:37.20

なるほど
こういう理解であってますか？
「Javaの検査例外」と「RustのResult/Optionエラー処理」を比較すると

(共通点)
以下をコンパイル時点で強制することで安全性を保証
「誰かがエラー時の捕獲と処理(Javaではcatch、Rustではmatch等)を必ずしていること」

(相違点)
Javaでは例外と同じtry-catchを利用 (そのため入れ子で例外が握り潰されたりややこしい)
Rustでは例外はなく通常の関数呼び出しと値返し処理となり、
関数の返す型がResultまたはOptionのenum型、
多段呼び出しの場合に途中で「?」使用によりエラー時にスルー可、
自分もしくは上位の誰かがResultまたはOptionのenum値をチェックしてエラー処理

Rustではエラー時にエラー表示して終了で良い場合は以下の楽にサボる方法もサポート
最上位のmain()がResult/Optionを返すことで自動的にエラー時に表示終了
ResultまたはOptionをunwrap()等してエラー時に即時panic終了
このpanic終了はスレッド単位やタスク単位も可能なのでサボりサーバー等も実装可

**デフォルトの名無しさん** · 2022/01/11(火) 23:52:36.57

Rustも呼び出し階層全てでどのエラーが発生しうるか型で管理しないといけないからJavaの検査例外と同じ面倒臭さがある

面倒臭いからといって全部Result<T, Box<dyn Error>>にしちゃうと何のエラーが発生するのか分からなくなってしまう

面倒臭さと堅牢さのトレードオフ

**デフォルトの名無しさん** · 2022/01/11(火) 23:58:57.17

>>572
dyn Error返しでもエラー処理自体は可能なので
Rustは様々なサボり方をサポートしつつ堅牢にすることもできる選択があるので良いと思います

**デフォルトの名無しさん** · 2022/01/12(水) 01:37:24.08

戻り値を返さないコンストラクタやデストラクタ内でエラーが発生したら、例外
以外に通知する方法があるなら教えてほしい。

例外ハンドラを書かないって、エラー処理を一切しない、例えばディスクが一杯で
書き込めないとか、何かあると問答無用で落ちるプログラムってことだぞ。

**デフォルトの名無しさん** · 2022/01/12(水) 01:42:57.07

例外 (panic) 以外ないね
エラーが発生しうる処理はデストラクタが呼ばれる前にやるべきかな
RustでもBufWriterなんかがスコープアウトでdrop呼び出される前に明示的にflush必要だったりする (drop内のcloseで発生するエラーは無視される)

**デフォルトの名無しさん** · 2022/01/12(水) 02:19:37.87

>>574
I/Oなどエラー発生の可能性が必ずありうるものはRustではResultが返る
唯一の例外がデストラクタすなわちRustではdrop
そこで問題になりうる可能性があるのはRAIIで自動的に呼ばれるデストラクタに依存して処理を行なうケース
エラーを捕捉したい時は>>575のように事前回避するがpanicさせてそれを捕捉も可能

**デフォルトの名無しさん** · 2022/01/12(水) 11:53:11.60

>>574
コンストラクタやデストラクタ内ではエラーが発生しないように作れって習わなかった？
それでも避けようのないエラーなら落としたほうがいい
プログラム全体を落としたくなければスレッドやプロセスを落とす

**デフォルトの名無しさん** · 2022/01/12(水) 12:24:49.11

C++で例外安全をちゃんとやるの難しそう

**デフォルトの名無しさん** · 2022/01/12(水) 12:30:04.82

>>577
デストラクタでエラーはまずいけどコンストラクタで避ける理由は無かろう。
[迷信] コンストラクタから例外を送出してはならない
https://www.kijineko.co.jp/%E8%BF%B7%E4%BF%A1-%E3%82%B3%E3%83%B3%E3%82%B9%E3%83%88%E3%83%A9%E3%82%AF%E3%82%BF%E3%81%8B%E3%82%89%E4%BE%8B%E5%A4%96%E3%82%92%E9%80%81%E5%87%BA%E3%81%97%E3%81%A6%E3%81%AF%E3%81%AA%E3%82%89/

**デフォルトの名無しさん** · 2022/01/12(水) 12:31:30.95

>>578 Rustなんかだと何か簡単になるの？

**デフォルトの名無しさん** · 2022/01/12(水) 12:54:54.70

unsafeのpanic-safeはそれなりに気を遣わないといけないよね
safeだと特に何も考えなくても良い？

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

C++は何種類もコンストラクタがあって大変だが
Rustはコンストラクタが無いため問題は発生しない
Rustにも自動で呼ばれるデストラクタはあるが
その前に捕獲すべきエラーが発生しうるものを自分で処理しておくので無問題

**デフォルトの名無しさん** · 2022/01/12(水) 20:35:54.02

俺はコンストラクタで例外投げないし投げさせないな
コマンドのような短命プロセスで雑な実装で良いとか、必然性があるなら別だけど

**デフォルトの名無しさん** · 2022/01/12(水) 21:30:33.58

コンストラクタと言ってるからc++だと思うけど事前条件を満たさないでコンストラクタが呼び出されたらどうするの？

**デフォルトの名無しさん** · 2022/01/12(水) 21:36:50.23

南無三！と叫びながらreturn

**デフォルトの名無しさん** · 2022/01/12(水) 22:39:14.21

>>583
> コマンドのような短命プロセスで雑な実装で良いとか
何その意味不明な必然性w

**デフォルトの名無しさん** · 2022/01/12(水) 22:42:53.89

いやわかるやろ
長期間安定して走らないといけないプログラムとそうでないのとはあるやろ

**デフォルトの名無しさん** · 2022/01/12(水) 23:16:19.38

>>584
ファクトリメソッド経由でしかコンストラクタは呼び出せないようにするんだよ

**デフォルトの名無しさん** · 2022/01/12(水) 23:43:13.07

コンストラクタでエラーが発生しないようにするのはリークの問題じゃなくて使いやすさの問題
new Hoge()を呼べるなら個別にハンドリングが必要なエラーは発生しないと分かるのが重要
デストラクタと違ってコーディング規約的なもの

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

>>589
コーディング規約(w

コンストラクタ内で、動的配列のクラスやテンプレートを使ってると、例外が発生する
可能性は常にある。　他の言語は知らんが、C++の場合、コンストラクタ内で例外が
発生すると、デストラクタは呼ばれない。

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

例えば、ファイルハンドルをラップしたファイルクラスがあったとして、引数なしの
デフォルトコンストラクタと、引数でオープン済のファイルハンドルを渡すコンスト
ラクタを定義したとして、後者のコンストラクタが無効なファイルハンドルを引数
として呼ばれたら、例外をスローするように実装するだろ？

後者のコンストラクタは、dup()で複製したファイルハンドル等を扱う際に必要。

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

>>591
ファイルハンドルが無効な場合をエラーとして処理すべきならコンストラクタを直接使わせずファクトリー経由にする
panic相当の例外として処理すべきならコンストラクタ使って例外スローでかわまない

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

>>587
それとコンストラクタで例外発生させないことは関係なくね？

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

コンストラクタも例外も存在しないRustでは問題自体が生じない
>>591のケースでもRustでは後者のビルダー関数がResultを返すだけで済む

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

Rustって、名前の通り錆付いてるようだな。　例外(Exception)がないって、要は
Panicって名前とtry～catchと互換性のない俺仕様の記述を発明しただけじゃん。

ttps://news.ycombinator.com/item?id=11370841
ttps://www.reddit.com/r/rust/comments/bzaxf2/why_rust_doesnt_have_exception_handling/
ttp://joeduffyblog.com/2016/02/07/the-error-model/

返す型を限定するのは、C++でもコーディング規約で縛れば済むだけの話だし。

結局、Nullポインタ程度で騒いでいるのは、マニュアルフォーカスのカメラでピンボケ
するとか、マニュアルミッションの車でクラッチ繋ぐのミスると、エンストするって
言ってるのと変わらん気がするナァ。

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

>>595
開発人数が増えると規約を守らせるコストが大きくなるからね

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

>>595
panicと例外は全く異なる
議論に立ち入りたいならばせめて最小限の理解をしよう
完成した通常のプログラムにおいてpanicが発生するのはメモリ不足の時のみ

次に、例外はそもそも必要ないことに気付こう
エラーが発生する可能性があるならばエラーを返せばよいだけだ
これでプログラミングにおいて困ることはない
try～catchの例外機構はそもそも必要のないものだったのだ

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

>>597
panicが発生したときの制御フローは通常のフローと同じなの？

もし違うのなら、通常フローへの復帰はどうやるの？

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

>>598
unwindingされてキャッチされるまでスタックが巻き戻るよ
例外と同じ

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

その点も含めて、少なくとも >597 の「全く異なる」は嘘だね。
後段の「エラーが発生する可能性があるならばエラーを返せばよいだけだ」についても、
じゃぁ何で panic があるの？ってなるし、どういうわけか例外憎しで適当なこと言いたいだけみたい。

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

rustのpanicとかエラーハンドリングの考え方はgolangの影響大きい気はする
Result型を使うか多値でエラーを返すかの違いはあるが、panicという名前と動作、戻り値との使い分けは同じ

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

なので >>595 のrustは俺仕様を発明したという指摘も事実と異なると思う

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

エラーモデルの理解が浅い人を寄ってたかって叩いたところで得るものはないぞ

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

>>598
panicはバグ発生かメモリ不足でのみ起きる。
だから通常フローへの復帰はせずにabortとなる。
abort前に後処理をしたい時やデバッグ情報を出したい時のためにstd::panic::catch_unwindがある。
それらの処理のためにスタックが巻き戻る。

>>600
一方でtry catch例外処理はpanicとは完全に異なるものである。
単なるエラー処理でも使われて通常フローへの復帰をする。
そのためtry catchが言語の構文となっている言語も多い。
GoやRustにはこの例外処理はなくtry catchも無い。

プログラミングにおいて、エラー処理のためのtry catch例外処理は本来不要なものである。
エラーは関数の戻り値で返せばよい。
このように本来のやり方でエラーを返すのがGoやRustであり、これで実際に動いている。
つまり、単なるエラー処理のための例外機構は必要ないものであることがわかる。

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

>>604
話が微妙に違うなぁ。

「エラー処理としての例外は不要(panicや例外みたいに制御フローが異なる機能は必要)」
という話と
「例外処理そのものが不要」
という話がごっちゃになっていない？

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

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

あらゆる関数/メソッド呼び出しのたびにエラーチェックをするのが煩雑だから、try-catchが生み出されたんだと思う。
例えば、データベースアクセスが発生する三つの関数を呼び出すとき、
try {
　　foo();
　　bar();
　　baz();
　　commit();
} catch () {
　　rollback();
}
みたいな。
続行不能なエラーが発生したが、本流に戻る必要があるときは便利。

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

>>605
話がごっちゃになっているのはtry catchの例外処理。

Rustでpanicが起きるのはバグとメモリ不足であり、絶対に起きてはいけない状況。
だからpanicの標準動作はそのままabortとなっている。
一方でエラー処理は起き得ることだから関数の戻り値で返す。

一方でtry catchの例外処理は、それらをごっちゃにまとめて扱っている。
単なるエラー処理を、なぜ、try catchで扱ってしまうのか？
それは関数の仕様設計ミスである。
ちゃんとエラーを返せば、単なるエラー処理のための例外処理は不要となる。

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

Rust擁護するあまり無理筋の論理展開だな
プログラミングに必須じゃない機能は不要と言い出したらキリないのでは

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

>>607
rustのpanicだってabuseできるし
べき論の話で言ったらC++もエラー処理には戻り値を使うべき

現在のベストプラクティスは両者とも大差ないのでは

**デフォルトの名無しさん** · 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

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