272(1): デフォルトの名無しさん (ﾜｯﾁｮｲ ef63-uLm/) [sage] 2024/02/17(土) 11:55:24.05 ID:hsYxYbKj0(1/2) AAS
>>250
>>2. fall-throughする関数が例外による処理の中断でおかしいことにならないか（←要テスト！
>もしそのテストが必要なんだとすれば、catchしない場合はその例外が通過する
>呼び出し階層全部でテストをしなきゃならないってことになるが。
その通り。テスト不要としたいなら、例外が出た原因を調べて出ないようにするのが筋

原因を調査して対策せずに予防的にテスト不十分のtry { } catch () をてんこ盛りにする方がソフトウェアー品質が上がるという考えのはおかしい

>>251
>catchする⇒無視する、握りつぶす　って脳内変換
脳内変換ではなくて、予防的に入れたtry { } catch ()部分のテストが不十分な限り事実じゃーん？

>>252
>本質的にやってること変わらないのに
別に。
return -1; は呼び出し側のバグで見落とすかもしれないが
throw std::logic_error("*** ERR ***"); なら悪評千里を走ってバグの兆候が嫌でもﾜｶﾙ
むしろ予防的なtry { } catch () が例外のメリットをreturn -1; に縮小してゐる

249(2): デフォルトの名無しさん (ﾜｯﾁｮｲ ef63-uLm/) [sage] 2024/02/11(日) 11:18:50.45 ID:4PD3HqyC0(5/5) AAS
>>244
以下の主張のどこが抽象論なのかkwsk、
1. ライブラリのドキュメントに従い、可能な限り例外を生じない使い方で設計する（>>236
2. 例外が生じない前提としたところは例外が生じないことをテストする（m個のオーダー）（>>229
3. 1と2の過程で意図に反して飛んでくる例外がある場合は原因を調査し、修正を試みる（>>228　例外が飛んで来たらバグ
4. 3を意図通りの形で解決できないことが判明した場合は
　　（ライブラリの使用方法の当方の誤解、ライブラリのドキュメントの不備、ライブラリの作りの粗さによりこれはあり得る、
　　結果的にtry { } catch (/*省略*/) { ... }を付ける可能性もある（>>228
5. 例外を複数段fall-throughか再スローを許し、かつそれが起きた後もプログラムの
　　正常な動作の継続を意図する場合はテストケースが爆発する(>>

設計し、検証し、必要とあらばtry { } catch ( ) の追加も含めた修正を行うと言っているのやぞ；；；

いっぽう藻前らの主張は
1. 例外をせき止めれば良い（←処理不能な未知の例外が飛んでくることが無いというライブラリに対する全幅の信頼
2. 例外を処理したりfall-throughしたり再スローしたりする関数はn*a*m個のテストしなくても動くっしょ
　（←自己のコードに対する無制限の気体
3. ドキュメントは100%信頼せず、読まない
の3成分からなるわけやが……