[過去ﾛｸﾞ]
C++相談室 part165 (1002ﾚｽ)
C++相談室 part165 http://mevius.5ch.net/test/read.cgi/tech/1698705458/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制
です｡10分ほどで解除するので､
他のﾌﾞﾗｳｻﾞ
へ避難してください｡
283: デフォルトの名無しさん (ﾜｯﾁｮｲ 1e85-XyAm) [] 2024/02/17(土) 23:18:00.46 ID:v62CV0mD0 >>278 > そもそも致命的な例外でアプリケーション自身の継続が困難な場合を除いて > どんな例外でもあっても継続的な処理を可能にするのが例外処理だろうに それは幻想 c++の例外安全の達成がどれだけ難しいか理解していないね 簡単にリークするし、オブジェクトが想定外の状態を持ったりする 動作保証ができない だから仕様に明示されていない例外が来たら基本は終了だよ そのまま継続してそれが原因でその後別の場所で落ちられたら無駄な調査の手間が増えるだけ http://mevius.5ch.net/test/read.cgi/tech/1698705458/283
287: デフォルトの名無しさん (ﾜｯﾁｮｲ e3f9-NGC7) [sage] 2024/02/18(日) 09:39:44.00 ID:9f8IS57r0 ぶっちゃけ>>283がなに言ってるのかわからない 継続してそれが原因で？ いやいやw 突如落ちるより、保存できるデータは保存してもらう機会を与えることは出来るだろ なんでお前は何事もなかったかのように作業を続ける前提でしか話を聞かないんだ？ オブジェクトの状態が変わっているかも？ 変更前のデータと比較して変わっていたらユーザに確認すればいいだろ 例えば図形情報のうちTopの読み込みで例外が発生した場合に想定してないからとアプリ落として全情報ロストさせる気か？ Topは０で初期化させ読み込めなかったことをユーザに伝えて修正、もしくは再読み込みの機会を与えるだけの話だろ http://mevius.5ch.net/test/read.cgi/tech/1698705458/287
288: デフォルトの名無しさん (ﾜｯﾁｮｲ cfcf-sYtR) [sage] 2024/02/18(日) 09:41:50.12 ID:WHoJTRhT0 >>285 >例外の種類しか頭にないのか >>283が仕様に明示されていない例外を話題にしているからだが。 >任意の場所での例外発生に対応するなん現実的にできないということ これはどういう意味なんだろうな。 着目するのは自分が呼び出している処理から上がってくる例外に対して例外安全かどうかであって それは基本的に局所的に判断できるもの。 下層の、例外が通過してきた処理が例外安全な実装になっているかどうかってのはそっちの責務。 http://mevius.5ch.net/test/read.cgi/tech/1698705458/288
298: デフォルトの名無しさん (ﾜｯﾁｮｲ 1b63-9XlH) [sage] 2024/03/02(土) 23:49:37.41 ID:C77pR/Zl0 >>284 例外安全というもののスコープに対して考察が足りていない 1. 例外安全なオブジェクト foo のデストラクトが他の例外によって引き起こされるケースでは foo の安全な終了は（メモリかファイルステムか何かが物理的にぶち壊れてOSがパニックになったとかでない限り ほぼほぼ保たれるから>>284のような言い方はできるっていやーできるが、 システム全体については>>283の通りであって全然安全ではない 2. fooの中の例外処理が本当に完璧かはfooのコードに書かれている全てのtry { } catch () について 全ての例外発生条件についてテストか厳格めのコードレビューでも行わないことには安全性が担保されない。 （つまり例外安全にした実装したと主張するだけでは話がただちには簡単にはならない http://mevius.5ch.net/test/read.cgi/tech/1698705458/298
299: デフォルトの名無しさん (ﾜｯﾁｮｲ 1b63-9XlH) [sage] 2024/03/02(土) 23:57:46.67 ID:C77pR/Zl0 それはそうとして、予防的なtry{ } catch () の何が一番駄目かというと、設計上のトレードオフをわけわかんなくすることが確実な点 例外発生後の状況というのはたいてい>>283の通りのわけなので、何かを捨てて何かを取る （例えばシステムは最悪落ちても構わないが、例外安全なオブジェクトfooでリソースAの整合性は死守する等） のトレードオフが発生するがそういうのこそ慎重な設計と考慮が必要な事項であることは確定的にあきらか プログラムの全階層にtry { } catch ()入れたら完璧などというｱﾌｫはやっぱtry { } catch () しないのが正しい http://mevius.5ch.net/test/read.cgi/tech/1698705458/299
305: デフォルトの名無しさん (ﾜｯﾁｮｲ 8b63-eOBD) [sage] 2024/03/04(月) 07:58:21.27 ID:KYG2Ugpe0 なんか予想外に低ﾚなレスポンスを寄越した>>299…… さすがに>>283の後に>>284のような楽天的なことを言えるだけのことはあるということか…… 例外安全は確かに目指すべき境地であり、例外安全なオブジェクトだけでコードを書けば その関数は例外安全となる。try { } catch ()など一切不要、となるわけで一見実現が簡単に思える が、例外安全なオブジェクトだけかをもれなく機械的に確認する方法は無い上に、 中断したら別物になる（処理の順序が命）というアルゴリズムというものの本質的特性により、 >>183 のような try { } catch () が必要なケースは隙あらば混ざり込んでくるから（※1） >>284が空想するようなシステム全体の例外安全化などは現実には不可能。 せいぜいある程度の規模のオブジェクトであれば、十分テストすれば （自分が呼び出す関数が例外安全にできているかどうかと自分の処理が例外安全かどうかを慎重に確認せねばならない） ほぼほぼの信頼度で実現できるというぐらい。 http://mevius.5ch.net/test/read.cgi/tech/1698705458/305
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.038s