[過去ログ] C++相談室 part165 (1002レス)
前次1-
抽出解除 レス栞

このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
251
(1): デフォルトの名無しさん (ワッチョイ 16cf-BOeC) [sage] 2024/02/11(日) 12:31:22.40 ID:XOPhWcHA0(5/5) AAS
>>249
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成分からなるわけやが……
>1
1(3): デフォルトの名無しさん (ワッチョイ efda-9b8G) [sage] 2023/10/31(火) 07:37:38.52 ID:+ZyYyqMO0(1) AAS
!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512
↑同じ内容を3行貼り付けること

次スレは>>980が立てること
無理なら細かく安価指定

※前スレ
C++相談室 part164
2chスレ:tech VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured
. 例外をせき止めれば良い(←処理不能な未知の例外が飛んでくることが無いというライブラリに対する全幅の信頼

なるほどな。
catchする⇒無視する、握りつぶす って脳内変換されてんだな。

catch書いたからといって上に挙げられたようなテストができなくなるわけじゃないっしょ。必要と思うならやればいい。

3.の意図しない例外の原因調査なんて main() に例外が上がってきてプログラムが落ちてからより
発生個所に近い下層で catch できた方がはるかに調査しやすいと思うんだがな。感覚が違うなあ。
272
(1): デフォルトの名無しさん (ワッチョイ ef63-uLm/) [sage] 2024/02/17(土) 11:55:24.05 ID:hsYxYbKj0(1/2) AAS
>>250
250(1): デフォルトの名無しさん (ワッチョイ 16cf-BOeC) [sage] 2024/02/11(日) 12:01:58.52 ID:XOPhWcHA0(4/5) AAS
>>248
>例外が関数の階層をぶち抜いてfall-throughしてくることを忘れている発言

やっぱり意味不明だな。catchすれば「階層をぶち抜いて」ってことはないわけだが。

>2. fall-throughする関数が例外による処理の中断でおかしいことにならないか(←要テスト!

もしそのテストが必要なんだとすれば、catchしない場合はその例外が通過する
呼び出し階層全部でテストをしなきゃならないってことになるが。
>>2
2(2): デフォルトの名無しさん (ワッチョイ 194e-FUJr) [sage] 2023/10/31(火) 08:59:52.78 ID:DBRUqQAF0(1) AAS
>1 乙です

前スレ 例外はループ脱出に使うような物じゃない、との意見に賛成です。

自分は、例外は「起こり得るけどいちいちエラー処理を書いたらアホな話を」「処理呼び出し毎ではないレベルで」「エラー対処コーディングするもの」と思ってます。

具体例は、
リンクリストなどコレクション操作でメモリ不足が起きた場合、のエラー処理。
コレクションの追加や削除を頻繁に行うコードって、大体はもっと概念レベルが高い事をやってるので、1件の追加 レベルでエラー処理書いてたらアホな感じになる。

しかも、GUI プロセスを作ってて何か上手く動かないから特定のエラーだけを画面に表示したい、など、ことさら明確に対処したい場合です。プロセスが落ちればいいだけなら、main()の外側、の仕様がやってくれる。

古い本の情報だけど、SBリップマンによると、MS VC++と、sun、hp-ux の C++コンパイラで、例外を使う/使わないで速度性能調査したそうで、 4~6% の速度劣化があったとの事です。
. fall-throughする関数が例外による処理の中断でおかしいことにならないか(←要テスト!
>もしそのテストが必要なんだとすれば、catchしない場合はその例外が通過する
>呼び出し階層全部でテストをしなきゃならないってことになるが。
その通り。テスト不要としたいなら、例外が出た原因を調べて出ないようにするのが筋

原因を調査して対策せずに予防的にテスト不十分のtry { } catch () をてんこ盛りにする方がソフトウェアー品質が上がるという考えのはおかしい

>>251
>catchする⇒無視する、握りつぶす って脳内変換
脳内変換ではなくて、予防的に入れたtry { } catch ()部分のテストが不十分な限り事実じゃーん?

>>252
252(1): デフォルトの名無しさん (スプッッ Sd52-oDfP) [sage] 2024/02/11(日) 12:37:47.91 ID:AyRTgUB7d(1) AAS
仕様書や規格書はその意図を正確に読み取ろうとするのに
掲示板の他人の書き込みは積極的に曲解しようとするのは何故か?
>本質的にやってること変わらないのに
別に。
return -1; は呼び出し側のバグで見落とすかもしれないが
throw std::logic_error("*** ERR ***"); なら悪評千里を走ってバグの兆候が嫌でもワカル
むしろ予防的なtry { } catch () が例外のメリットをreturn -1; に縮小してゐる
前次1-
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル

ぬこの手 ぬこTOP 0.035s