[過去ﾛｸﾞ]
C++相談室 part165 (1002ﾚｽ)
C++相談室 part165 http://mevius.5ch.net/test/read.cgi/tech/1698705458/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
必死ﾁｪｯｶｰ(本家)
(べ)
自ID
ﾚｽ栞
あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
297: デフォルトの名無しさん (ﾜｯﾁｮｲ 1b63-9XlH) [sage] 2024/03/02(土) 23:41:07.84 ID:C77pR/Zl0 >>282 >相変わらずずれてるな。 catch する == 原因を調査しない じゃないわけ >249に賛同いただけていないということは、発生してもいない例外について予防的にtry { } catch () を入れようとしていることは 確定的に明らか で、例外というﾌﾞﾂは「例外なく」悪い知らせなので（∵仮に良い知らせを例外で寄越すライブラリがあったらそれ自体悪い知らせである 普通の人は悪い知らせが来る前に処置しようとする。すわなち例外が来ないように（可能な限り）修正する。 try { } catch ( ) でひっかけて原因調査兼確実な修正でざい、それが一番効率が良い方法論である、などと主張するのはおかしい人だけ…… http://mevius.5ch.net/test/read.cgi/tech/1698705458/297
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
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.041s