[過去ﾛｸﾞ] C++相談室 part165 (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
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 ***"); なら悪評千里を走ってバグの兆候が嫌でもﾜｶﾙ
戻り値のチェック漏れは静的局所的にチェックできるが例外は出てみなけりゃ結局澪とされるわけだが。
リリース後にユーザーサイドでその見落とされていた例外が発生してプログラムが落ちたりしたらそれはただのバグ。
297: デフォルトの名無しさん (ﾜｯﾁｮｲ 1b63-9XlH) [sage] 2024/03/02(土) 23:41:07.84 ID:C77pR/Zl0(1/3) AAS
>>282
>相変わらずずれてるな。 catch する == 原因を調査しない じゃないわけ
>249に賛同いただけていないということは、発生してもいない例外について予防的にtry { } catch () を入れようとしていることは
確定的に明らか
で、例外というﾌﾞﾂは「例外なく」悪い知らせなので（∵仮に良い知らせを例外で寄越すライブラリがあったらそれ自体悪い知らせである
普通の人は悪い知らせが来る前に処置しようとする。すわなち例外が来ないように（可能な限り）修正する。
try { } catch ( ) でひっかけて原因調査兼確実な修正でざい、それが一番効率が良い方法論である、などと主張するのはおかしい人だけ……
307: デフォルトの名無しさん (ﾜｯﾁｮｲ 8b63-eOBD) [sage] 2024/03/04(月) 08:09:49.95 ID:KYG2Ugpe0(3/3) AAS
あと寝てて思ったがプロセスが死んでもサービスが継続したらお客様には迷惑を掛けずに済むので
（直接そういうのをやってちるわけではないので強くは言わんが
ウォッチドッグタイマー的な死活監視で異常あらばプロセス再起動とかマシンを切り替えるとか方法はいくつもあって、
十分テストされたプログラムならクラッシュ頻度をポアソン分布とみなして信頼度も出せる
やっぱ「お客様の前で落ちたら恥ずかしいから」というつまらないプライドを基本的動機とする
try {
....
} catch (std::exception& e) {
log_e("std::exceptionがスローされました");
};
みたいなコードをリリースコードに含めましょうという>>282の調査のスタンスは全く正当化されない
100日に一回しか再現しないバグの修正を3日でやれと言われて手元にあるのがメモリダンプの代わりに上の23文字のログメッセージだけだったりしたら
>>282は自○が真剣に考慮すべき選択肢に……
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.034s