289(1): デフォルトの名無しさん (ﾜｯﾁｮｲ e3f9-NGC7) [sage] 2024/02/18(日) 12:27:32.99 ID:9f8IS57r0(2/3) AAS
> これはどういう意味なんだろうな。
そうそれ

tryブロックで囲った部分（つまり任意）の例外発生に対応するのが例外処理なのになにが出来ないというのか
想定している例外が発生して継続できると判断したなら続ければいいし
ダメならユーザに通知してもちょも安全な方法を選択させればいい
でもってそれは想定していない例外の発生でも同じ
ただ致命的でどうしようもないなら強制終了させるだけの話で、想定していない例外はなんでもかんでも強制終了じゃ例外処理使う意味が薄まってしまう

299(2): デフォルトの名無しさん (ﾜｯﾁｮｲ 1b63-9XlH) [sage] 2024/03/02(土) 23:57:46.67 ID:C77pR/Zl0(3/3) AAS
それはそうとして、予防的なtry{ } catch () の何が一番駄目かというと、設計上のトレードオフをわけわかんなくすることが確実な点

例外発生後の状況というのはたいてい>>283の通りのわけなので、何かを捨てて何かを取る
（例えばシステムは最悪落ちても構わないが、例外安全なオブジェクトfooでリソースAの整合性は死守する等）
のトレードオフが発生するがそういうのこそ慎重な設計と考慮が必要な事項であることは確定的にあきらか
プログラムの全階層にtry { } catch ()入れたら完璧などというｱﾌｫはやっぱtry { } catch () しないのが正しい

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

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

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