[過去ﾛｸﾞ] C++相談室 part165 (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
244(2): デフォルトの名無しさん (ﾜｯﾁｮｲ 1e27-2ki6) [sage] 2024/02/11(日) 09:47:48.79 ID:2tL2xZqD0(2/3) AAS
>>242242(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 637c-IqbK) [sage] 2024/02/11(日) 09:29:04.38 ID:9XvrSVak0(1/2) AAS
例外は「関数外にエラー発生を伝える」ための「方法の一つ」でしかない
関数の処理がどんなエラーを発生させうるか、受け取った外側の処理がその情報をどう取り扱うべきかという問題とは完全に直交してる
（言語ごとにある程度の慣例はあるけどあくまで慣例）
例外に変なこだわりや的外れな批判をしてる奴は大体そこを勘違いしてる
お前はバグのないお花畑を考えてるからそういう理想的な抽象論を持ち出すんだよ
c++の現実は道を踏み外したら即カオス
stlのコンテナのpopに返り値がない理由は知ってるか？
あのレベルの考察でソフトウェア設計している人間が世の中にどれだけいると思う？
246: デフォルトの名無しさん (ﾜｯﾁｮｲ 637c-IqbK) [sage] 2024/02/11(日) 10:07:06.72 ID:9XvrSVak0(2/2) AAS
>>244
バグのあるなしなんか関係ない設計の話だし、「例外はエラー伝達の具体的方法の一つ」って話のどこが抽象的なのかも分からないし、
「C++の現実」とか「カオス」が具体的に何のことで何の関係があるかも分からないし
STLにpopがないのはnoexcept moveがない時代に例外安全に出来なかったからだけど今の話に何の関係があるかわからないし
そんなのまともなC++erなら誰だって考えて設計してると思うけど、そうでないタコの話が何の関係あるかわからないし何もかも分からなすぎてすごい
仕事でそんなドキュメントやレビューコメント出すなよ
>>245知らない例外を握り潰すのも、知らない戻り値をガン無視するのも一緒
errnoが変わってるのを無視するのもint*err引数に渡した変数の値を無視するのもexpected<T,E>で帰ってきたEを無視するのも「知らんエラーを無視した」という結果は一緒
知らんエラーを無視していいかどうかの意味論と、そのエラーがどう伝播して来るかかは関係ない
関係ない話を混ぜるからお前のC++はカオスなんだよ
249(2): デフォルトの名無しさん (ﾜｯﾁｮｲ ef63-uLm/) [sage] 2024/02/11(日) 11:18:50.45 ID:4PD3HqyC0(5/5) AAS
>>244
以下の主張のどこが抽象論なのかkwsk、
1. ライブラリのドキュメントに従い、可能な限り例外を生じない使い方で設計する（>>2362. 例外が生じない前提としたところは例外が生じないことをテストする（m個のオーダー）（>>229229(2): デフォルトの名無しさん (ﾜｯﾁｮｲ 5763-dZsi) [sage] 2024/02/10(土) 12:26:53.58 ID:KJGevrBa0(2/2) AAS
>>186
>catchしたらテストケースが増えるかどうかという話とはなんも関係がない。
あっる
catchする必要性箇所を設計で厳選すればcatchが減るのだからテストケースは減らし得る
例外を使う場合：
スルーしたりcatchして再スローが生じるfoo()の呼び出し箇所（とするのが現実的でないなら呼び出しﾊﾟﾃｨｰﾝ）がm個、
スルーしたりcatchして再スローする段数が（簡単のためここでは平均とする）a個、
foo()が例外を生じるﾊﾟﾃｨｰﾝがn個なら、m^a^n個のテストケースが必要なところであるが
catchする必要性箇所を設計で厳選した場合：
foo()の呼び出し箇所（とするのが現実的でないなら呼び出しﾊﾟﾃｨｰﾝ）がm個だとしたら、
例外が飛んでこないことを確認するのテストケースがm個のオーダーで要るだけ……
3. 1と2の過程で意図に反して飛んでくる例外がある場合は原因を調査し、修正を試みる（>>228228(3): デフォルトの名無しさん (ﾜｯﾁｮｲ 5763-dZsi) [sage] 2024/02/10(土) 12:18:06.78 ID:KJGevrBa0(1/2) AAS
>>185
>>183の主張の
>一方、例外を生じないライブラリの使い方（関数の呼び出し方）を心掛けるかどうか。これなら選択肢がある
が完全に読み飛ばされている件について：
例外を生じないライブラリの使い方で設計したら、funcB()から例外が飛んでくるのはバグなので
調査と修正の対象になる。
（結果的にやっぱtry { funcB(); } catch (/*略*/) { ... } いるじゃーん？となる可能性はあるがたいていはそうはならない
>>188のように自分が何をやっているのか認識しないまませき止めるのは論外すぐる……
例外が飛んで来たらバグ
4. 3を意図通りの形で解決できないことが判明した場合は
（ライブラリの使用方法の当方の誤解、ライブラリのドキュメントの不備、ライブラリの作りの粗さによりこれはあり得る、
結果的にtry { } catch (/*省略*/) { ... }を付ける可能性もある（>>228
5. 例外を複数段fall-throughか再スローを許し、かつそれが起きた後もプログラムの
正常な動作の継続を意図する場合はテストケースが爆発する(>>
設計し、検証し、必要とあらばtry { } catch ( ) の追加も含めた修正を行うと言っているのやぞ；；；
いっぽう藻前らの主張は
1. 例外をせき止めれば良い（←処理不能な未知の例外が飛んでくることが無いというライブラリに対する全幅の信頼
2. 例外を処理したりfall-throughしたり再スローしたりする関数はn*a*m個のテストしなくても動くっしょ
（←自己のコードに対する無制限の気体
3. ドキュメントは100%信頼せず、読まない
の3成分からなるわけやが……
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.058s