282(2): デフォルトの名無しさん (ﾜｯﾁｮｲ 16cf-BOeC) [sage] 2024/02/17(土) 20:37:07.00 ID:QSMcEn770(1/2) AAS
>>272
>原因を調査して対策せずに予防的にテスト不十分のtry { } catch () をてんこ盛りにする方がソフトウェアー品質が上がるという考えのはおかしい

相変わらずずれてるな。 catch する == 原因を調査しない　じゃないわけ。

>return -1; は呼び出し側のバグで見落とすかもしれないが
>throw std::logic_error("*** ERR ***"); なら悪評千里を走ってバグの兆候が嫌でもﾜｶﾙ

戻り値のチェック漏れは静的局所的にチェックできるが例外は出てみなけりゃ結局澪とされるわけだが。

リリース後にユーザーサイドでその見落とされていた例外が発生してプログラムが落ちたりしたらそれはただのバグ。

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成分からなるわけやが……

284(3): デフォルトの名無しさん (ﾜｯﾁｮｲ 16cf-BOeC) [sage] 2024/02/17(土) 23:48:07.59 ID:QSMcEn770(2/2) AAS
例外安全と例外の種類には特に関係はないわけで、知らない例外だと例外安全の保証が困難になるなんてこともない。

283(5): デフォルトの名無しさん (ﾜｯﾁｮｲ 1e85-XyAm) [] 2024/02/17(土) 23:18:00.46 ID:v62CV0mD0(1) AAS
>>278
> そもそも致命的な例外でアプリケーション自身の継続が困難な場合を除いて
> どんな例外でもあっても継続的な処理を可能にするのが例外処理だろうに

それは幻想
c++の例外安全の達成がどれだけ難しいか理解していないね
簡単にリークするし、オブジェクトが想定外の状態を持ったりする
動作保証ができない
だから仕様に明示されていない例外が来たら基本は終了だよ
そのまま継続してそれが原因でその後別の場所で落ちられたら無駄な調査の手間が増えるだけ