例外処理
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2006/03/18(土) 16:37:260002デフォルトの名無しさん
2006/03/18(土) 16:43:010003デフォルトの名無しさん
2006/03/18(土) 16:56:140004デフォルトの名無しさん
2006/03/18(土) 17:59:05Enum系含んだ構造体で値返せばいいの？
0005http://www.vector.co.jp/soft/win95/util/se072729.html
2006/03/18(土) 18:02:480006デフォルトの名無しさん
2006/03/18(土) 18:09:350007デフォルトの名無しさん
2006/03/18(土) 18:35:16こういうところでは、こういう例外処理を入れたほうがいいよ、
みたいな情報が欲しい。
0008デフォルトの名無しさん
2006/03/18(土) 21:18:170009デフォルトの名無しさん
2006/03/18(土) 21:45:020010デフォルトの名無しさん
2006/03/18(土) 22:16:270011デフォルトの名無しさん
2006/03/18(土) 22:37:00詳しく。
0012デフォルトの名無しさん
2006/03/18(土) 23:14:54例外種類をのなら、その構造体でも行けるかもしれないけど
スタックの巻き戻しも無い・再throwも無い・・・
なので、例外の恩恵に与るには程遠い
0013デフォルトの名無しさん
2006/03/18(土) 23:39:42そしてVCやBCCなら構造化例外処理がある。
0014デフォルトの名無しさん
2006/03/19(日) 00:36:020015デフォルトの名無しさん
2006/03/19(日) 00:37:20ＣＥの開発だとＣ＋＋だけどthrowが無いとか聞いたけど。
0016デフォルトの名無しさん
2006/03/19(日) 00:41:22するなあ。
もう関数呼ぶたびに戻り値のチェックなんてしたくない
な
0017デフォルトの名無しさん
2006/03/19(日) 00:50:51エラー コードを返したり、グローバル変数の設定したりすることと
同レベルだと思ってはいけません。例外は、それを取り巻くコードの
構造と意味を、根底から覆します。例外は、プログラムの実行時
セマンティックを一時的に繋ぎ変え、通常実行しているコードを迂回し、
こういう状況でなければ決して実行されないコードを動作させます。
例外は、エラー状態を認知させ、プログラムの死という罰則を用いて
その状態を改めようとします。
このように、例外には単純なエラー処理を超えた特性があります。
これらの特性を必要としない、理解しない、あるいは文書化したく
ないなら、例外をスローしてはいけません。
例外以外のエラー処理技法を探してください。
0018デフォルトの名無しさん
2006/03/19(日) 00:51:39なんか胸がスッとしたよ。
0019デフォルトの名無しさん
2006/03/19(日) 00:53:24コンパイラによって実装が違ったりするの？
そーゆー違いについて書いてるページとか無いですか？
0020デフォルトの名無しさん
2006/03/19(日) 01:00:55そうか？それはJavaの例外は否定ということか？
問題はエラーとか例外の定義だよな
これは人よってとらえ方が違うからな。
そしてこれは関数一つ一つに細かく考えなきゃ
いけないからまたたちが悪い。
例えばファイルの削除に失敗した場合はどっち？
OreSocket::Sendに失敗した場合はどっち？
とかさ
0021デフォルトの名無しさん
2006/03/19(日) 01:17:50たとえばVCの例外機構はWindowsのOS機能として用意されている
SEH(構造化例外処理)の上に構築されていて、
UNIX系OSではSEGVで停止するようなHW例外も捕捉できる。
Mingwのcatchではこういうことはできない。
（ただしMingwにはSEH対応パッチみたいなものは存在している。）
0022デフォルトの名無しさん
2006/03/19(日) 01:28:40ガリガリっとスタックを（半ば無理矢理）巻き戻していく
というのが俺の認識だな
直前の関数で catch されるなら戻り値でエラーを返すのとほぼ一緒だけど、
コールスタックを2段以上一気に巻き戻せるのが特徴的に見える
しかしこいつの天変地異的な効果のせいで
プログラムが不必要にややこしくなった気もしないでもない
0023デフォルトの名無しさん
2006/03/19(日) 01:29:07gcc,vcで結構違うな
0024マイク ◆yrBrqfF1Ew
2006/03/19(日) 01:30:03EOFを認める。
0025デフォルトの名無しさん
2006/03/19(日) 01:36:22ことだろ？
0026デフォルトの名無しさん
2006/03/19(日) 01:52:00http://msdn.microsoft.com/library/ja/jpdndeepc/htm/deep02172000.asp
だからどうってわけじゃないけど。
0027デフォルトの名無しさん
2006/03/19(日) 02:00:09そこいいね
0028デフォルトの名無しさん
2006/03/19(日) 02:01:19途中までコンストラクタ、デストラクタからのスローについて誤認したまま語ってるので注意。
まぁ古い記事だからしょうがないだろう。
0029デフォルトの名無しさん
2006/03/19(日) 02:04:34C++ では throw() 以外使わないのがお勧め。
0030デフォルトの名無しさん
2006/03/19(日) 02:12:48throw() 以外って、何か他にあったっけ？
0031デフォルトの名無しさん
2006/03/19(日) 02:21:55投げる例外をキッチリ書くこと。
0032デフォルトの名無しさん
2006/03/19(日) 02:47:39中途半端に、例外を使うコードと、使わないコードを混在させるな。
0033デフォルトの名無しさん
2006/03/19(日) 02:51:24ttp://www.amazon.co.jp/exec/obidos/ASIN/4891004967/250-6168173-4357044
こいつにいくつか書いてたな
0034デフォルトの名無しさん
2006/03/19(日) 03:31:03http://boost.cppll.jp/HEAD/more/generic_exception_safety.html
例外処理の実施
http://msdn2.microsoft.com/ja-jp/library/seyhszts.aspx
Javaの理論と実践: 例外をめぐる議論
http://www-06.ibm.com/jp/developerworks/java/040618/j_j-jtp05254.html
あと書籍
Exceptional C++ の2章
「例外安全に関する問題点とテクニック」
0035デフォルトの名無しさん
2006/03/19(日) 14:11:42他人が投げる例外って、色んな例外の形式が混在して、嫌じゃない?
0036デフォルトの名無しさん
2006/03/19(日) 15:50:51C++での話でつ。
0037デフォルトの名無しさん
2006/03/19(日) 16:05:420038デフォルトの名無しさん
2006/03/19(日) 18:04:05...で捕らえてればいいでしょ、とりあえず。ドキュメントが
しっかりしてるのはそれを捕まえればいいし。
>37
まね。例外なんてつかわねー、なんて言ってらんないしね。
stlもcastもnewも例外投げてくるし。
とにかくリソースを確保したりする箇所では、catchしないと
だめだめだね
0039デフォルトの名無しさん
2006/03/19(日) 19:23:59関数の返り値でエラーを返して、呼び出し側でチェックするのと、変らないじゃないですか。
例外をcatchするだけでは、何かエラーが起きて処理を中断したことしか、わからないじゃないですか。
エラー内容を表示したり、ログに記録したり、そういったことをするためには、ただcatchするだけじゃぁ・・・。
理想を言えば、
たとえば、インタラクティブな操作がないコマンドラインで動くプログラムなら、
try〜catchは、main関数ただ一ヶ所に書いて済むようにしないと。
0040デフォルトの名無しさん
2006/03/19(日) 19:47:49うーんとね、こまめにするかどうかは自分が書くコードによるよ。
例えばさ
A* a = new A;
a->f(); ← 1
*a = "test"; ← 2
delete a;
1で例外きたらまずいでしょ。2の演算子だって例外を投げるかも
しれないでしょ。例外はどこからでも飛んでくることを想定して
なきゃいけないんだよ。だからなるべく、メモリを確保するとか
DBに繋げるとかリソースを確保する関係のコードとか、この区間で
例外が来たらまずいというコード量を少なくすることが必要なの。
それが例外セーフなソースを書くということで、その辺のことが
上記の偉い人たちが書いた本に書いてるから読んでみ
0041デフォルトの名無しさん
2006/03/19(日) 19:55:090042デフォルトの名無しさん
2006/03/19(日) 20:36:010043デフォルトの名無しさん
2006/03/19(日) 20:41:53mallocやnewをカプセル化しないのが悪い。
0044デフォルトの名無しさん
2006/03/19(日) 20:44:48人によくSTLを直に使わないのはどうして? と聞かれるけど、
例外をthrowするから
と答えると、try〜catchすればいいとか言われる。
0045デフォルトの名無しさん
2006/03/19(日) 20:45:230046デフォルトの名無しさん
2006/03/19(日) 21:20:54エラーコードのint型を投げる奴とか、エラーメッセージのchar*型投げる奴とか・・・
なんでC++はスタック上の std::exception 以外投げられないように設計しなかったのか小一時間・・・
004746
2006/03/19(日) 21:22:46なんでこんなにレベルの低い本が平然と流通するのかねぇ・・・
004846
2006/03/19(日) 21:26:120049デフォルトの名無しさん
2006/03/19(日) 21:47:30＞一番ヌッ殺してやろうかと思った奴は、__LINE__を投げつけてきた奴
assertと勘違いしている悪寒。
0050デフォルトの名無しさん
2006/03/19(日) 22:01:30なんでもありなのがC++ですから。
>>47
それは同感。
せめてstd::exceptionくらい載せろよと思う。
0051デフォルトの名無しさん
2006/03/19(日) 22:11:02__LINE__だけじゃぁなぁ。
__FILE__も一緒に投げてもらわないと。
0052デフォルトの名無しさん
2006/03/19(日) 23:29:55どうなりますか？
0053デフォルトの名無しさん
2006/03/19(日) 23:33:55基本的にプログラムが終了する。
終了する前に何するかは言語による。
0054デフォルトの名無しさん
2006/03/20(月) 01:12:38そういう問題じゃないんだよ・・
0055デフォルトの名無しさん
2006/03/23(木) 23:40:120056デフォルトの名無しさん
2006/03/24(金) 00:16:14思い切って告白したら例外処理された、、、
0057デフォルトの名無しさん
2006/03/24(金) 00:22:37例外処理されるだけありがたいと思えよ。例外処理されるようなお前はその子にとっては特別な存在だと思うぜ。
俺なんてうまく処理された振りをされて騙されたぜ...彼女バグ持ちだったんだ...
0058デフォルトの名無しさん
2006/03/24(金) 00:58:300059デフォルトの名無しさん
2006/03/24(金) 02:47:17きっとお前が「エラーが出ないようにしろ」タイプで
彼女は「出ないようにしました」タイプだったのさ
0060デフォルトの名無しさん
2006/03/24(金) 14:17:12いや違うんだ。彼女はそうかもしれんけど、俺はダメならダメって言って欲しいんだ。
それなら早く諦められるから。
0061デフォルトの名無しさん
2006/03/28(火) 00:28:33Error Handling A Pattern Language
http://www.objectarchitects.de/arcus/cookbook/exhandling/index.htm
日本語で書いてあるもので、いい文書知りませんか？
26,33-34以外のやつで。
0062デフォルトの名無しさん
2006/03/28(火) 17:15:17理解しろ。話はそれからだ。
0063デフォルトの名無しさん
2006/03/28(火) 18:05:41throw __LINE__
throw __FILE__
っがだめってこと？
0064デフォルトの名無しさん
2006/03/28(火) 18:07:47究極的には「いかに try-catch を書かずに済ませるか」だと思う．
0065デフォルトの名無しさん
2006/03/28(火) 18:50:17何かいいことあるの？
0066デフォルトの名無しさん
2006/03/28(火) 18:52:26宝くじに当たるわ
彼女が出来るわ
でいいことずくめ
0067デフォルトの名無しさん
2006/03/28(火) 18:55:28朝起きたら、背中だけでなく足にも腫物ができてやがった。
犬どものオリがやけに静かなんで、足引きずって見に行ったら数が全然たりねえ。
めしを三日抜いたくらいで逃げやがって。
おえら方に見つかったら大変だ。
May 16, 1998
昨日、この屋しきから逃げ出そうとした研究いんが一人、射さつされた、て はなしだ。
夜、からだ中 あついかゆい。
胸のはれ物 かきむしたら 肉がくさり落ちやがた。
いったいおれ どうな て
May 19, 1998
やと ねつ ひいた も とてもかゆい
今日 はらへったの、いぬ のエサ くう
May 21, 1998
昨日PSPをもらってからすっかり体調も良くなった。
さらに職場で気になっていたあの娘から今晩デートに誘われた。
昇進も決まったし、今最高の気分です。
投げてよかった std::exception
0068デフォルトの名無しさん
2006/03/28(火) 19:35:410069デフォルトの名無しさん
2006/03/28(火) 19:41:56std::exceptionというよりも、その派生クラスを投げておけば、
例外を受け取る方はstd::exceptionだけを受け取れば済む。
0070デフォルトの名無しさん
2006/03/28(火) 19:43:151行毎にtry〜catchで囲んでいて、
だったら返り値でやれよ!!!
と言いたくなるようなソースを見たことがある。
実際に言ったら、エラーを例外ではなく返り値で返すラッパーを作って使うようになった。
0071デフォルトの名無しさん
2006/03/28(火) 23:07:12うーーむ。
奥が深い。
正にその通り。。
0072デフォルトの名無しさん
2006/03/28(火) 23:51:03ATLは変えられるけど、プロジェクト作る度に設定するのが面倒くさい。
007361
2006/03/29(水) 00:04:35レスありがとうございます。
「C++の設計と進化」はすでに読み終ってます。
感想としては先に「ARM」のほうを読んでいたため、例外処理の部分はあまり参考になりませんでした。
0074デフォルトの名無しさん
2006/03/29(水) 00:22:200075デフォルトの名無しさん
2006/03/29(水) 01:25:48究極的でなくても最近のアプリはウィンドウクラスすらtemplateになっている
例外はエンドユーザのためのインターフェースじゃないのかと
0076デフォルトの名無しさん
2006/03/29(水) 05:05:300077デフォルトの名無しさん
2006/03/29(水) 08:56:34いや，汎用コンポーネントでも try-catch は使うべきところでは
普通に使うと思いますよ．
汎用コンポーネントの場合， "exception neutral"（例外中立）もしくは
"exception transparent"（例外透明）という概念が重要になると思います．
これらの概念に対向する概念として "exception translation" というのが
ありますけれど，これもコンセプトに例外仕様が明記されるような
汎用コンポーネントでは，使用されても特に問題はないように思います．
0078デフォルトの名無しさん
2006/03/29(水) 11:42:35int ret = 0;
try{
if(!func1())throw 1;
if(!func2())throw 2;
if(!func3())throw 3;
...
}catch(int e){
ret = e
}
... // 開放処理
return ret;
}
な使い方じゃ駄目？
0079デフォルトの名無しさん
2006/03/29(水) 12:52:20そんでその女子中学生にいきなり振り向かれて
「せ、責任とってお嫁に貰ってください・・・」
って言われちゃったんだ。
俺は慌てちゃってさ
「・・え？は、はぁ・・・」
みたいに返してそのまま通り過ぎようとしたら
俺のシャツをﾁｮｺﾝと指で掴んでずっとついてくるのね。
そんでとうとう家までついて来ちゃってさ
「はじめてですけど覚悟は出来てます・・・」
とか言うわけよ。
俺もう理性が吹っ飛んじゃって
（全てを読むにはstd::exceptionを投げてください）
0080デフォルトの名無しさん
2006/03/29(水) 12:57:470081デフォルトの名無しさん
2006/03/29(水) 13:31:04std::exception ex;
throw ex;
}
0082デフォルトの名無しさん
2006/03/29(水) 17:06:540083デフォルトの名無しさん
2006/03/29(水) 17:42:33別に例外を使う必要がないコードじゃない？
0084デフォルトの名無しさん
2006/03/29(水) 18:36:36あたりの__LINE__なげちゃだめとかint投げちゃだめって何で？
throw MyException( __LINE__, __FILE__ );
って俺やってんだけどこれってだめなの？
0085デフォルトの名無しさん
2006/03/29(水) 19:24:27008684
2006/03/29(水) 19:36:41ごめん。C++の前に日本語勉強するわ。
0087デフォルトの名無しさん
2006/03/29(水) 20:31:10void find_(tree *t, int key) {
if (t->val == key) throw t;
else if (!t->left) find_(t->left, key);
else if (!t->right) find_(t->right, key);
}
みたいなコードが書けなくて困るだろ。
0088デフォルトの名無しさん
2006/03/29(水) 20:47:57一般的に例外の throw と catch でもって値のやりとりをするのはよろしくない
実装にもよるが、大抵の場合かなり遅い
以前、例外で値を返すフィボナッチを作って g++ でコンパイルして走らせてみたが、
笑えるくらい遅かった
0089デフォルトの名無しさん
2006/03/29(水) 21:18:2687 は禿本で良い書き方といわれてることを知ったうえでの発言だろうな？
0090デフォルトの名無しさん
2006/03/29(水) 21:32:180092デフォルトの名無しさん
2006/03/29(水) 22:12:59消 極 的 に な っ て き ま し た
0093デフォルトの名無しさん
2006/03/29(水) 22:28:58戻り値をNULLと比較するのはNULLがノードなしに対応していることを知らないといけない。
0094デフォルトの名無しさん
2006/03/29(水) 23:07:340095デフォルトの名無しさん
2006/03/29(水) 23:21:14同感
0096デフォルトの名無しさん
2006/03/30(木) 00:15:41>>94
同意
0097デフォルトの名無しさん
2006/03/30(木) 00:36:56所謂、最低な例外の使い方の一つ
>>94
激同
正常系で例外を投げてる時点で、例外使う資格無し
0098デフォルトの名無しさん
2006/03/30(木) 04:27:24例外を投げる可能性があるのかどうかハッキリする
というのは、C++にも欲しい機能だと思う。
C++では、どんな例外が上がってくるのか、さっぱりわかんないんだもの。
0099デフォルトの名無しさん
2006/03/30(木) 08:40:44C# がその機能を破棄したのは何故か、知っておくといい。
0100デフォルトの名無しさん
2006/03/30(木) 09:41:20「例外を投げる可能性があるのかどうか」だけなら
throw() の有る無しでハッキリするよ。
きっちり使ったほうがいいんだろうけど、あんまり付けてないな。
デストラクタとか全部付けなきゃいけなくなってメンドクサイ。
0101デフォルトの名無しさん
2006/03/30(木) 19:03:22自分が呼んだ関数の先で投げたのがスルーされて自分に飛んでくるのも含めて、
膨大になり杉。
0102デフォルトの名無しさん
2006/03/30(木) 20:11:25とりあえず、自分から呼び出した先での例外は、すべてcatchすれば、、、
やっとれんわな。
0103デフォルトの名無しさん
2006/03/30(木) 22:22:250104デフォルトの名無しさん
2006/03/30(木) 22:26:080105デフォルトの名無しさん
2006/03/30(木) 23:10:550106デフォルトの名無しさん
2006/03/31(金) 20:00:59教えて、何で？
0108デフォルトの名無しさん
2006/03/31(金) 21:45:38まあ、なんだか分からんけど、成功してないのは確か、までは分かるしな。
0109デフォルトの名無しさん
2006/03/32(土) 00:26:54??何故に？？
0110デフォルトの名無しさん
2006/03/32(土) 03:16:53http://msdn.microsoft.com/vcsharp/programming/language/ask/exceptionspecs/
0111デフォルトの名無しさん
2006/03/32(土) 09:27:1339
0112デフォルトの名無しさん
2006/03/32(土) 12:55:420113デフォルトの名無しさん
2006/03/32(土) 20:00:03それって、関数にどんな例外を投げるかちゃんと指定しろって事だろ。
0114デフォルトの名無しさん
2006/03/32(土) 21:00:180115デフォルトの名無しさん
2006/03/32(土) 21:07:38ということは、つまり
バージョンが上がれば、想定していないような例外が上がってくる可能性がある
ということなわけで、つまり
例外の識別は諦めろ
ってことなんだな。
0116デフォルトの名無しさん
2006/04/02(日) 11:36:29って不味い手かな？
0117デフォルトの名無しさん
2006/04/02(日) 14:54:16戻り値だとああすっきりと書けない。
0118デフォルトの名無しさん
2006/04/03(月) 23:27:55時と場合によるかと
MyException がRuntime errorを表わすのなら大蟻
0119マイク ◆yrBrqfF1Ew
2006/04/04(火) 04:27:38基底クラスで指定しとけばいいんじゃねえの？
派生させて投げられるジャン？
0120デフォルトの名無しさん
2006/04/04(火) 07:33:59浅はかなり。
それだと意味がわからないぐらい抽象的な指定しかできなくなる。
または無茶な継承を容認せざるを得なくなる。
0121デフォルトの名無しさん
2006/04/08(土) 00:28:14Func();
}
を抜けるのに、例外使っちゃだめ？
たとえば、Funcで、非同期recvしてて、ユーザーがExitボタン押した場合とか。
0122デフォルトの名無しさん
2006/04/08(土) 01:14:40while( 1 )
{
Dispatch();
}
って感じで、状況によって違う関数を常に送出してます。
最初はifで判定して、ループを抜けてたんですが、
try
{
while()...
}
catch( MyException &E )
{
if( E.code() == USER_EXIT ){ status = SUCCESS; }
else{ status = ERROR }
}
みたいなコードの方が綺麗かな。と思いまして。
ただ、正常系で例外使うなって話があったんで、だめかなぁと。。。
0124デフォルトの名無しさん
2006/04/08(土) 11:27:18「正常系で例外を使うな」なんて指標にすぎないんだから、
使ったほうが綺麗にかけるならどんどん書くべき。ただしコメントは必須。
0125デフォルトの名無しさん
2006/04/08(土) 12:41:50確実に「なんでこうしたの？」って聞かれるだろうな。
例外はオーバーヘッド増えるよ。
0126デフォルトの名無しさん
2006/04/08(土) 13:12:42具体的なオーバーヘッドってどんなものなんですか？
0127デフォルトの名無しさん
2006/04/08(土) 13:45:130128デフォルトの名無しさん
2006/04/08(土) 13:57:31とにかくオーバーヘッドがかなりかかるらしい
詳しくは以下が参考になると思う
http://www.microsoft.com/japan/msdn/columns/csharp/csharp07192001.asp の「例外処理とパフォーマンス」
http://www.microsoft.com/japan/msdn/vs_previous/visualc/techmat/feature/jangrayhood/ の「例外処理」
どっちもC++の例外について多くを語ってくれてるわけではないが参考程度にはなるはず
0129123
2006/04/08(土) 14:07:350130デフォルトの名無しさん
2006/04/08(土) 14:36:03そもそも最適化かけるには面倒な条件が多いし、あまり頻繁に起こらない部分に
最適化をかけても意味がないというのもある
0131デフォルトの名無しさん
2006/04/08(土) 14:38:49この程度の認識でオーバーヘッドだコストだと言っているとは。
リスクを減らすために言語レベルでの質の高い安全策を使うのだから
リスクの残る糞自前コードを使うよりオーバーヘッドがあるのは当然のことだ。
0132デフォルトの名無しさん
2006/04/08(土) 14:39:550133デフォルトの名無しさん
2006/04/08(土) 14:47:25個人的には >>17 を読んでねとしかいえない。
>>131
例外はどういうふうに処理されるのでしょうか？
参考にさせていただきたいので書籍やサイトをご教示ください。
書籍は「Advanced Windows」以外の本でお願いします。
0134デフォルトの名無しさん
2006/04/08(土) 15:20:16Deep C++だとアセンブリコードを見つつどうなっているのかを解説している。
ttp://msdn.microsoft.com/library/ja/jpdndeepc/htm/deep070199.asp
他にもlongjmpとかDwarf2で検索すれば不毛の道を突き進むことができる。
健闘を祈るよ。
0135123
2006/04/08(土) 15:43:11でも私はスマートに書ける場面なら、例外を使ってもいいと思うんです。
なので皆さんの意見を聞きたかったのですが。
とりあえず我流でいきますー。
0136デフォルトの名無しさん
2006/04/08(土) 15:47:17人の意見を取り入れる気がないなら聞くな
0137133
2006/04/08(土) 16:27:38なるほど、アセンブリを読むんですね。
longjmpで検索してみたら、いろいろ出てきたので調べてみます。
教えてくださりありがとうございました。
0138デフォルトの名無しさん
2006/04/08(土) 21:16:47クラスBがクラスCのインスタンスを生成している場合、
クラスCの実行時例外はクラスBでキャッチするの？
0139デフォルトの名無しさん
2006/04/08(土) 22:09:47ソースコードでおｋ
0140デフォルトの名無しさん
2006/04/08(土) 22:36:05>エラー条件を処理する古風な方式の代替手段を提供する。経験的に，その予期しない値は，呼出し元で
>無視されるか又は検査されないことが多いことが知られており，頑健的でない若しくは望ましくない振る舞い
>又はその両方をプログラムにもたらす。
例外の強力なところは
例外時の処理の実装の必要性を意識させるってことだろ？
try〜catchを使えばコードが必ず見やすくなるというものではないし、
try〜catchでもcatchしわすれた例外があれば
実行時に落ちてプログラム自体が終了してしまうし
0141デフォルトの名無しさん
2006/04/09(日) 01:19:58エラー処理ができる。例外のメリットはそれだけだろ？
下請け側で頻繁にtry〜catchするのが前提の関数書くくらいなら返値でおｋ
0142デフォルトの名無しさん
2006/04/09(日) 14:44:46スタックトレースのようなものを、ログに取りたいんですが、どうすればいいんでしょうか？
0143デフォルトの名無しさん
2006/04/10(月) 00:10:370144デフォルトの名無しさん
2006/04/10(月) 01:14:020145デフォルトの名無しさん
2006/04/10(月) 01:46:440146デフォルトの名無しさん
2006/04/11(火) 05:36:51他にどのようなものがありますか。
0147デフォルトの名無しさん
2006/04/11(火) 15:08:01ハンドラチェインのまき戻りだけでえらい時間が掛りますよ
0148デフォルトの名無しさん
2006/04/11(火) 22:51:51例外が発生した時に、その例外を扱うハンドラを探す処理の事でしょうか。
0149デフォルトの名無しさん
2006/04/16(日) 01:11:05なんでthrow 123;とか throw "string";
が駄目なんですか？
0150デフォルトの名無しさん
2006/04/16(日) 01:38:300151デフォルトの名無しさん
2006/04/16(日) 01:46:44まったく意味がわからないんです。
今までにもintを投げるなという議論は見かけたのですが、
具体的理由が書かれてなくてわからないんです。
死んでるスタックを参照するからですか？
0152デフォルトの名無しさん
2006/04/16(日) 01:50:21使い勝手の問題。
0153デフォルトの名無しさん
2006/04/16(日) 01:52:47使い勝手が悪い。ということなのでしょうか？
てっきりスタックが絡んできてでんでんだと思ってたのですが、、
0154デフォルトの名無しさん
2006/04/16(日) 02:38:410155デフォルトの名無しさん
2006/04/16(日) 02:44:54あるライブラリは「問題の発生したソースコード内の行番号を int で throw します」という
仕様だったとする。使う側は catch(int line) などで補足することになるだろう。
もうひとつのライブラリは「errno と同様の値を int で throw します」という仕様だったとする。
この二つのライブラリを同時に使おうとすると、 catch(int line) と catch(int error)
ってことになってエラーになる。
ソースコード内の行番号をエラーメッセージに出すのも、いい考えだとは思わない。
0156デフォルトの名無しさん
2006/04/16(日) 03:35:52理解できました。別にスタックが絡んでくるわけじゃなかったんですね。
ありがとうございました。
0157デフォルトの名無しさん
2006/04/16(日) 06:37:16何でもいいからクラスに包んで投げれば、受け取る側も選別しやすいっしょ？
0158デフォルトの名無しさん
2006/04/16(日) 08:29:52エラーの内容はcatch側で勝手に解析関数呼べって素敵仕様さ。
#つーか、どうせmain()でその内容表示してreturnするだけだがな。
0159デフォルトの名無しさん
2006/04/16(日) 09:14:04std::exceptionから派生させようぜ。
what()を書くだけで済むから。
0160デフォルトの名無しさん
2006/04/16(日) 20:47:590161デフォルトの名無しさん
2006/04/16(日) 22:03:000162デフォルトの名無しさん
2006/04/16(日) 23:17:29おすすめの教科書あったら教えてください！
0163146
2006/04/17(月) 14:05:210164デフォルトの名無しさん
2006/04/17(月) 14:12:48実測してみたら?
0165デフォルトの名無しさん
2006/04/18(火) 03:31:32速度は実測が基本。
ましてや例外処理については実装による差が大きいので、実測しかない。
0166デフォルトの名無しさん
2006/04/18(火) 12:07:43C++ 使いの僕はひどく驚いた。
0167デフォルトの名無しさん
2006/04/19(水) 18:48:09D&Eにもtryって別に要らないんだけど格好付けのために一応やっとくか
みたいな事書いてあった気がする。
0168デフォルトの名無しさん
2006/04/19(水) 21:03:30漏れは try の中で生成したインスタンスを try の外で
使いたい、というおかしなコードを書いてしまって、
右往左往した経験がある。
0169デフォルトの名無しさん
2006/04/27(木) 23:30:33それとも、もっと良い書き方あるんでしょうか？
0170デフォルトの名無しさん
2006/04/27(木) 23:37:21いつどこで例外が起きてもリークが起きないようにしている。俺は。
0171デフォルトの名無しさん
2006/04/28(金) 11:36:460172デフォルトの名無しさん
2006/04/28(金) 12:23:400173デフォルトの名無しさん
2006/04/28(金) 17:45:33すでにあるよ。
0174デフォルトの名無しさん
2006/04/28(金) 17:59:190175デフォルトの名無しさん
2006/04/28(金) 18:13:160176デフォルトの名無しさん
2006/04/28(金) 21:24:130177デフォルトの名無しさん
2006/04/28(金) 23:57:29間違えてEffective C++
買っちまいそうだな。
コレと間違えてEfficent C++
買ってたからなｗ
0178デフォルトの名無しさん
2006/04/29(土) 00:28:070179デフォルトの名無しさん
2006/04/29(土) 04:22:09おまいは俺の知人かｗ
0180デフォルトの名無しさん
2006/04/29(土) 04:41:440181デフォルトの名無しさん
2006/05/01(月) 00:18:07Eroticだろ
0182デフォルトの名無しさん
2006/05/01(月) 02:35:390183デフォルトの名無しさん
2006/05/01(月) 11:11:280184デフォルトの名無しさん
2006/05/01(月) 11:40:320185デフォルトの名無しさん
2006/05/01(月) 22:02:510186デフォルトの名無しさん
2006/05/01(月) 23:06:170187デフォルトの名無しさん
2006/05/02(火) 01:17:320188デフォルトの名無しさん
2006/05/02(火) 01:58:590189デフォルトの名無しさん
2006/05/04(木) 15:12:10ってエラーがでたんだけれども、これどういうこと？
これ以外にも
非標準の拡張機能が使用されています : 'MyClass::hoge' は SEH と デストラクタ を含む 'str' 使われています。
って怒られた。もうわけわかめ。
alloca使った後でSTATUS_STACK_OVERFLOWを捕まえたいだけなのに・・・
0190デフォルトの名無しさん
2006/05/04(木) 18:16:290191デフォルトの名無しさん
2006/05/06(土) 02:22:40コンパイラの仕事を人間さまにやらせてるって感じ。
C#は書かないでも勝手にthrowしてくれるからよいね。
0192デフォルトの名無しさん
2006/05/06(土) 15:05:030193デフォルトの名無しさん
2006/05/06(土) 21:25:05__tryの中にデストラクタがあるオブジェクトを置くことはできない。
それをどうにかするには、allocaを使わないかSEHをC++例外にしてしまえばいい。
俺のお勧めは前者。SEHを使うなというわけではなくallocaなんて要らないだろという理由から。
後者の方法を取るならここが参考になる
http://msdn.microsoft.com/library/ja/jpdndeepc/htm/deep03162000.asp
ちなみにオブジェクトアンワインディングとはデストラクタを実行すること。
0194デフォルトの名無しさん
2006/05/06(土) 23:23:38レスありがとう。デストラクタがあるとまずいのか。
Warningのほう（非標準云々)見て大丈夫なのかと思ったけど違うのね。
SEHは言語を意識したものではないからなのかな？
とりあえず3Dモデリング関連で可変長のバッファを
チョコチョコ取りたいから後者を試してみるよ。
静的に確保したバッファーから割り当てる関数を
書く自信がないせいでもあるんだけどorz
0195デフォルトの名無しさん
2006/05/07(日) 00:27:40FirefoxのnsISupportsばりの#defineを1時間弱かけて書いたんだけど、
>テンプレート ベースのパターンを代わりに採用すれば、
>ここで示した継承パターン放棄してもかまいません。
はよ言わんかーー！！
0196デフォルトの名無しさん
2006/05/08(月) 10:45:490197デフォルトの名無しさん
2006/05/10(水) 15:21:220198デフォルトの名無しさん
2006/05/10(水) 18:28:540199デフォルトの名無しさん
2006/05/21(日) 15:43:34それとも、
できるだけ例外投げてこないようにデータを前もってチェックするべきか
思想はどちらが良いのですか？
0200デフォルトの名無しさん
2006/05/21(日) 15:52:37なんてありえない発想だ。そんなの例外でもなんでもない。
ファイルは無くて当たり前、なのだ。
ただし、そのファイルがプログラムの継続にどうしても必要なDBだったとか、
の場合だと話は違ってくる。つまりそのコンテナを使ってる”側”のことだ。
0201デフォルトの名無しさん
2006/05/21(日) 15:55:33俺の場合は、そもそもチェックや例外が極力必要ないようなデータ定義にすることに注力する。
チェックや例外が必要であればあるほど、その分プログラムは肥大化しバグも増えれば開発・メンテの工数も増える。
0202デフォルトの名無しさん
2006/05/22(月) 05:01:54「ファイルなんて誰かが消してるかもしれないし、ないかもしれないだろう？だから、それは例外じゃないんだ」っていう言い回しは
「例外」という単語を「想定外」という意味で捕らえすぎている日本人には誤解されやすい。
「ああ、じゃあエラーはエラーでも、はじめから起こり得ると分かっているエラーなら例外は使うべきじゃないんだな」
なんてトンチンカンな論理に繋がっちまう人が多すぎ。（うちの社内研修でも）
どんなエラーだってプログラマが想定した上でエラーコードなり例外をスローするわけで、
本当にプログラマの想定外のエラーなら、例外すら投げられずプログラムが強制終了するだけ。
起こりうるかどうか、ではなくて、「プログラムの実行に支障を来すエラーなのかどうか」で区別すべきなんだが…
そういうのをうまく説明する方法はないものなのか。
0203デフォルトの名無しさん
2006/05/22(月) 08:21:32なんてアプリケーションなら後者は例外だな。
0204デフォルトの名無しさん
2006/05/22(月) 08:33:19“例外”という特殊な状況が存在するかのように錯覚してしまうこと・・・だと思う。
あくまでエラーハンドリングの手法の一つであることを強調すべきだなぁ
0205デフォルトの名無しさん
2006/05/22(月) 10:01:59システム的なエラーは例外。
基本はこれでしょ。
0206デフォルトの名無しさん
2006/05/22(月) 10:21:000207デフォルトの名無しさん
2006/05/22(月) 10:22:52http://www.boost.org/more/error_handling.html
ここの "When should I use exceptions?" なんてどうだ？
0208デフォルトの名無しさん
2006/05/22(月) 10:45:03おお、まさにその内容ですな(´Д｀)
今度ペーパーにして配るわ。ﾄﾝｸｽ。
0209デフォルトの名無しさん
2006/05/22(月) 23:31:35http://boost.cppll.jp/HEAD/more/error_handling.html
0210デフォルトの名無しさん
2006/05/23(火) 00:59:050211デフォルトの名無しさん
2006/05/23(火) 23:16:41あのさあ、例外を「投げる」側のコードを書いている人間と、
そのコードを呼び出す側のコードを書いてる人間が同じだって前提に
無意識に立ってるからそういうトンチンカンな認識になるんだよw
例外の目的は、言ってみればフェイルセーフでしょ。
フールプルーフだよ。
0212デフォルトの名無しさん
2006/05/23(火) 23:20:44どれにレス付けてんだ？
0213デフォルトの名無しさん
2006/05/24(水) 00:04:06お前だよｗｗ
0214デフォルトの名無しさん
2006/05/24(水) 00:10:540215デフォルトの名無しさん
2006/05/24(水) 00:15:41意見が対立してるわけじゃないように見えるんだが、
なぜ >>211 は煽り気味なのか？
だれかまとめてくれ。
0216デフォルトの名無しさん
2006/05/24(水) 01:31:270217デフォルトの名無しさん
2006/05/24(水) 18:25:34assertってそういうときに使うもんだよな。
これが例外だとなんか気持ち悪い。
0218デフォルトの名無しさん
2006/05/24(水) 23:08:41「自分が使う」なら同意。
0219デフォルトの名無しさん
2006/05/24(水) 23:55:160220デフォルトの名無しさん
2006/05/25(木) 00:00:29他人が使うからこそ、だと思うが。
0221218
2006/05/25(木) 00:17:30「assertでもかまわん」というのは、「ノーチェック（もしくは即死）でもかまわん」ってことだよな？
んで、「他人が使う」ってことはリリースされてるってことだろ？
リリースされてるからには引数間違いなんかは十分起こりうるわけで、
それをノーチェックや即死にしていいの？
0222デフォルトの名無しさん
2006/05/25(木) 00:30:490223デフォルトの名無しさん
2006/05/25(木) 02:48:290224デフォルトの名無しさん
2006/05/25(木) 03:28:07デバッガで止まってくれるし
リリース時にも残しておく、普通のチェックには例外使う
0225デフォルトの名無しさん
2006/05/25(木) 10:35:46ATL/WTLやMFCのようなassertの使い方はダメだと申すのか?
0226デフォルトの名無しさん
2006/05/25(木) 14:46:18221 の他人は アプリﾕｰｻﾞｰ
0227デフォルトの名無しさん
2006/05/25(木) 19:29:540228デフォルトの名無しさん
2006/05/25(木) 19:44:000229デフォルトの名無しさん
2006/05/25(木) 21:14:52ライブラリを作るやつは好きにしてくれと俺は思う。
0230デフォルトの名無しさん
2006/05/25(木) 23:06:33InvalidArgumentとかをcatchして、ユーザーにはなんか深刻なエラーがでたような
メッセージに偽装して表示してるコードは見たことあるな。
0231デフォルトの名無しさん
2006/05/26(金) 01:03:220232デフォルトの名無しさん
2006/05/27(土) 12:37:460233デフォルトの名無しさん
2006/05/27(土) 12:47:52俺は例外だろうとは思っているが、
APIは戻り値でエラーを知らせるから、惰性で例外処理を使わない。
0234デフォルトの名無しさん
2006/05/27(土) 13:04:210235デフォルトの名無しさん
2006/05/30(火) 10:23:50try
{
}catch(...)
{
>ここ
};
0236デフォルトの名無しさん
2006/06/15(木) 20:28:17C#とかJavaなんかでは、例外をきちんと特定してキャッチするようにって言われてるよな。
まとめて一気にキャッチすんなと。
で、まとめてキャッチするのはエントリポイントでのみだ。
ここでは想定外の例外しかキャッチしないはずで、
ここでやるのはログを取ってアプリを落とす作業だ。
でも、普通、テスト漏れとかあって、たまに想定外の例外が発生することがあるよな。
漏れは今までどんなアプリでも落としちゃうようにしていたのだが、
特にずっと動かさなければならないサービスの場合は落とすなって言うヤツがいるんだ。
サービスの場合って落としちゃうのと落とさないのどっちがいいの？
0237デフォルトの名無しさん
2006/06/15(木) 20:37:08ケースバイケース。
例外が起こっても無理やり続けておかしな挙動になってもいいのか悪いのか。
これを問いただせ。
もしそれでも構わないというならログでも吐いとけ。
0238デフォルトの名無しさん
2006/06/15(木) 20:40:35外部から再起動掛かることが保証されているなら落とすのが無難。
そうでなくて、常に動いていることが要求されるなら自分自身を再起動するのも一つの手。
その例外の内容が致命的でないなら言われる通り落とさなくてもいいかもしれない。
要は、ケースバイケース。
0239236
2006/06/15(木) 20:45:20ありがとう。
0240デフォルトの名無しさん
2006/06/15(木) 21:48:15Webサービスなら、そのリクエストを無かった事にしてほっとく。
Webアプリなら、セッション殺してエラーページに遷移させてほっとく。
当然、リソースは例外が上までぶっ飛ぶ最中にfinallyでcloseされてるのが前提な。
普通のアプリは…、知らん。業務でプログラム組んだのはWeb系しかないぽ。
0241デフォルトの名無しさん
2006/06/15(木) 22:09:11そういう前提があってのことだよな。
というように、やっぱりケースバイケース。
0242デフォルトの名無しさん
2006/06/16(金) 00:06:06一応ダイアログで表示はするけどそのまま続行してしまう。
0243デフォルトの名無しさん
2006/06/17(土) 13:14:16殺さない処理系の場合、例外の発生によって被害が進みまくったら最悪だが…。
0244デフォルトの名無しさん
2006/06/17(土) 15:38:52ちょっと教えて欲しいのですがそれは適切な例外処理を書いてなかった場合の事ではないのですか?
端的に言えば例外処理をきちんと書いておけば問題ないのではないでしょうか?
0245デフォルトの名無しさん
2006/06/25(日) 14:54:540246デフォルトの名無しさん
2006/08/31(木) 16:41:360247デフォルトの名無しさん
2006/09/01(金) 02:37:26http://www.radiumsoftware.com/0608.html#060823
0248デフォルトの名無しさん
2006/09/01(金) 02:40:160249デフォルトの名無しさん
2006/09/01(金) 04:08:060250デフォルトの名無しさん
2006/09/01(金) 12:15:42Exception（例外）を捕まえて何かしら対処した時点でError（間違い）。
そもそも視点が違うと思う。
Exceptionが引き起こされるのがエラー処理だし。
不適切なパラメータ渡されたときにエラー（間違い）チェックして例外飛ばしたとして、
それを受けてユーザーに再入力促すような処理はエラー処理だし、
そのままスルーしたらその段階でも想定してなかった例外処理と言える。
0251デフォルトの名無しさん
2006/09/01(金) 18:26:210252デフォルトの名無しさん
2006/09/01(金) 23:03:260253デフォルトの名無しさん
2006/09/01(金) 23:11:240254デフォルトの名無しさん
2006/09/02(土) 00:14:01Error：言語によって違う
だから一概にどうとは言えない
なんて言う仕様原理主義の奴は氏ね
0255デフォルトの名無しさん
2006/09/02(土) 00:45:570256デフォルトの名無しさん
2006/09/02(土) 01:07:46仲良くみなさん一緒に逝って下さい
0257デフォルトの名無しさん
2006/09/06(水) 17:19:15/:::::::::::::::::::::::::::/ ・／ :::ゝ､
l::::::::::::::::::::::::::::i ： ! :::::::,!
──i^'i──┼''┴┬┬┬─--─''
i ヽ､ __! 'ﾞi;:;:;;!／ /
ヾ、 ￣`⌒ﾞ ` ,ﾉ
''ｰ-､,, ,;. ､,f
|,､ !, !
f, ,y | ,ﾍ
／´ ,ﾉ ,!、 // ＿ r=､
,/ ,;-'' ｀ヽ ﾞ; i^'i ;'､===ｮ ﾞiヽ＼
.,,-=二二i＿_i 二二二ヽ _i ヽ､二! 'ﾞi;:;:;;!／ /`"
l::::::::::::::::::::::::::::i ： !、 ￣ヾ、 ￣`⌒ﾞ ` ,ﾉ
ヽ::::::::::::::::::::::::::ﾞ､；ヽ ﾞ''ｰ-､,, ,;. ､,f
＼::::::::::::::::::::::::＼ ：ﾞ''- ,,,__ _.. | '" i ﾞ|
` ──----−`'''ｰ---- ''".|,､ !, !
. f, ,y |
／´ ,ﾉ ,!、
,/ ,;-'' ｀ヽ ﾞ;
i i ヽ ヽ、
0258デフォルトの名無しさん
2006/09/06(水) 17:29:470259デフォルトの名無しさん
2006/09/06(水) 17:37:000260デフォルトの名無しさん
2006/09/06(水) 23:23:110261デフォルトの名無しさん
2006/09/27(水) 02:42:49C++での話。例外仕様ってどうやって使ってる?
今までデストラクタやswapにthrow()と書いていたんだけど、
unexpectedするだけでさほど意味ないんじゃないかと思うようになって。
0262デフォルトの名無しさん
2006/09/27(水) 02:53:42throw() は最適化に使われることがある。逆にパフォーマンスダウンする
コンパイラもあったが、もう昔の話と言えるかもしれない。
デストラクタに throw() を付けてないクラスのローカル変数を大量に含んだ関数を
コンパイルしたアセンブリ見て、あまりのアホコードに愕然としたことがある。
throw() 付けたら、だいたい思ったとおりのコードになってくれた。
gcc で std::exception を継承した例外クラスを作るとき、デストラクタを
明示的に宣言して throw() 付けないと警告でる。中身が空でも throw() を
指定するためだけに宣言が要る。
throw() 以外の例外仕様はうんこ。
0263デフォルトの名無しさん
2006/09/27(水) 02:56:25例外投げるときは「責任が負えないが起こったとき」に限定してるから
どんなときでも「責任外」なら投げちゃってる俺ガイル
0264261
2006/09/27(水) 22:30:53参考になった、ありがとう。
脳内イメージでは "foo() throw() { body(); }" は
"foo() { try { body(); } catch (...) { std::unexpected(); } }" だったんで、
例外中立じゃないし余計なコードが入りそうに思ってた。
でも、デストラクタの場合は
「スタック巻き戻し中に例外が発生したら std::terminate() を呼ぶ」
って縛りがあるから、throw() が付いている方が最適化しやすいのかも。
わからんけど。
結局状況次第っぽいかな… いろいろ試してみるしかないか。
> throw() 以外の例外仕様はうんこ。
同意。欲張らず、コンパイル時の不送出保証をコードとして
記述できるようにだけしてくれれば、わりと満足なんだけどなー。
0265デフォルトの名無しさん
2006/09/27(水) 22:49:370266デフォルトの名無しさん
2006/10/01(日) 14:02:210267デフォルトの名無しさん
2006/10/01(日) 21:12:28C++で「例外仕様」って言ったら特別な意味があるんだよ…
0268デフォルトの名無しさん
2006/10/01(日) 22:27:29C++の例外はなぁ……
例外安全・例外中立とか、Exceptional C++呼んでもｻﾊﾟｰﾘだった俺には使いこなせそうにない
0269デフォルトの名無しさん
2006/10/01(日) 22:38:47そいつらがｻﾊﾟｰﾘならC++に限らず、例外処理（エラー処理）のある
プログラムは書けないだろうね。
0270デフォルトの名無しさん
2006/10/01(日) 22:42:44そんなこともわかんないようじゃ、C++も他のプログラムもちゃんとやってないんだね。
0271デフォルトの名無しさん
2006/10/01(日) 22:43:06"例外中立" の検索結果 約 73 件中 1 - 10 件目 (0.16 秒)
んー…んぅ・・・
0272デフォルトの名無しさん
2006/10/01(日) 22:52:04例外安全性って、言語に依存せずに定義できるもんだと思うんだが、違うのか？
言葉の意味の幅としてはスレッドセーフと同じようなもんだろ。
「C++の例外安全」って何？
0273デフォルトの名無しさん
2006/10/01(日) 22:55:390274デフォルトの名無しさん
2006/10/01(日) 23:17:15>>34
0275デフォルトの名無しさん
2006/10/01(日) 23:35:20バカ丸出しだな
0276デフォルトの名無しさん
2006/10/01(日) 23:51:10http://www.google.com/search?num=50&hl=ja&q=%22exception+safety%22
http://www.google.com/search?num=50&hl=ja&q=%22exception+neutral%22
http://www.google.com/search?num=50&hl=ja&q=%22exception+transparent%22
0277デフォルトの名無しさん
2006/10/01(日) 23:54:07例外安全は C++ に限らず、プログラム一般の概念だ。
言語は問わず、たとえ C でも例外安全性を語ることは出来る。
0278デフォルトの名無しさん
2006/10/02(月) 00:04:13まるでwikipediaに書いてあるかのように錯覚させるのはどうかと思うが。
ま、Cでも多少語ることが出来るが、本が書けるほどじゃない。
C++に比べるととてもシンプルだ。
Exceptional C++が理解出来ないとしても
>例外処理（エラー処理）のある
>プログラムは書けないだろうね。
はとんだアホレスだ
0279デフォルトの名無しさん
2006/10/02(月) 00:10:39"A piece of code is said to be exception-safe if run-time failures within the code
will not produce ill-effects, such as memory leaks, garbled data or invalid output."
に依るならばかなり普遍的な概念に読めるけれど
0280デフォルトの名無しさん
2006/10/02(月) 00:12:39俺からだ。Cに例外が無いので例外安全も糞もねぇ。戻り値しっかり調べてろアホ。
はい、お前の番。
0281デフォルトの名無しさん
2006/10/02(月) 00:14:360282デフォルトの名無しさん
2006/10/02(月) 00:25:38いえですから私の理解では，言語仕様としての exception （例外）と
wikipedia に書かれている exception safety （例外安全）を明確に区別しているだけです．
私の理解では，たとえばCにおいてある関数が例外安全であるといったとき，それは
Cにおいてはその関数内でのエラー・例外的状況の通達手段が戻り値
（もしくはmutableな引数，グローバルな状態）しかないというだけで，
仮にそれらの通達手段で例外的な状況・エラーが通達されているとき，プログラムの状態
（非常に曖昧な言葉ですが，これはmutableな引数の状態からグローバルな変数の状態，
ひいてはプログラムが実行されている環境の状態全てを指しえます）
が無効 (invalid) な状態に陥ってないことと定めることができる，というものです．
そして， wikipedia の文言もこう読めるのではないかという主張です．
0283デフォルトの名無しさん
2006/10/02(月) 00:34:45C++での例外安全を理解出来なかったからといって
次のようなアホなことは到底言えない。
>例外処理（エラー処理）のある
>プログラムは書けないだろうね。
0284282
2006/10/02(月) 00:38:18あ，すいません．自分は277さんの
＞例外安全は C++ に限らず、プログラム一般の概念だ。
＞言語は問わず、たとえ C でも例外安全性を語ることは出来る。
というレスに対してのみ賛同しているだけで，
＞>例外処理（エラー処理）のある
＞>プログラムは書けないだろうね。
という主張をしたいわけではないです．
0285デフォルトの名無しさん
2006/10/02(月) 00:39:12俺には自演にしかみえん
0286デフォルトの名無しさん
2006/10/02(月) 00:39:23C++でそれを達成するのが難しく理解が困難。わかる？
0287デフォルトの名無しさん
2006/10/02(月) 00:40:31なんで C だと簡単になるの？ C++ みたいに言語のサポート無いから余計に難しいだろ？
0288デフォルトの名無しさん
2006/10/02(月) 00:41:16282氏はWikipediaの内容をかいつまんでるだけ
(あそこでは例外処理がエラー処理と同等の文脈で使われてることのみを確認している)
で、他になんか主張を混ぜてるようには読めないけど。
0289デフォルトの名無しさん
2006/10/02(月) 00:42:57それはマジで言ってるの？
0290デフォルトの名無しさん
2006/10/02(月) 00:44:34ネタでもマジでもどっちでもいいから、C++では難しくて
Cでは難しくないと言う根拠を示してください。
0291デフォルトの名無しさん
2006/10/02(月) 00:45:05なんで皆なにも分かって無いのにウダウダ言ってるの？
バカじゃない？
0292デフォルトの名無しさん
2006/10/02(月) 00:48:02Cには例外機構がないから。
0293デフォルトの名無しさん
2006/10/02(月) 00:51:28例外機構が言語に組み込まれてなければ例外が起こらないと、そういう認識なのね。
また「例外」の定義からやりなおしですか？
0294デフォルトの名無しさん
2006/10/02(月) 00:59:39はぁ？何いってんの？
>C++では難しくてCでは難しくないと言う根拠を示してください。
根拠を示したのに、
>例外機構が言語に組み込まれてなければ例外が起こらないと、そういう認識なのね。
って解釈するって、どんだけアホなんですか。
0295デフォルトの名無しさん
2006/10/02(月) 01:00:07と余計にややこしい事を言ってみるテスト
0296デフォルトの名無しさん
2006/10/02(月) 01:01:23とかの方が例外安全なコードの書きやすさに貢献してくれそう。
0297デフォルトの名無しさん
2006/10/02(月) 01:03:29try-catch のあるなしだと、
それが goto 文という名前か、
try-catch かの違いでしかないような。
0298デフォルトの名無しさん
2006/10/02(月) 01:22:35例外機構の言語によるサポートがあったほうが
例外安全性の確保は簡単になると思っているので、
「Cでの例外安全達成が難しくない理由」と >>292 とが
結びつかない。
俺、アホなのかな？
0299デフォルトの名無しさん
2006/10/02(月) 01:46:01一輪車で事故らない方法
どっちが簡単か？
一輪車はそもそも転ばないように乗り回すものだから、危険は承知。
とりあえず車道に出るやつはいねえだろうし。結論は簡単に出る。
自動車の事故は、ドライバーの状態・車体の状態・環境なんか複雑な要件が絡むので
議論は多岐にわたる。こいつは難しい。
通りすがりに訳の分からない例えをしてみる。
0300デフォルトの名無しさん
2006/10/02(月) 03:54:29一輪車で遠くまで移動しなきゃならないこともある。
などとさらに通りすがりがツッコミを入れてみる。
まじめな話、「〜という(大規模な)処理をするプログラムを作れ。
言語はC限定。エラー対策は万全にしろ」と要求されることもある。
Cだから簡単ということはない(し、できないということもない)。
C++のように言語が例外機構を備えているなら、エラー処理の実装に
例外を適切に用いれば、より簡潔な記述で正しく実装できる。
ただし、当たり前だが使い方を間違えると意味がない。
0301デフォルトの名無しさん
2006/10/02(月) 08:48:440302デフォルトの名無しさん
2006/10/02(月) 11:10:24ごめんなさい
0303デフォルトの名無しさん
2006/10/02(月) 13:51:13漏れはいつでも「この関数longjmpで抜けていったりしねーだろうな。
リソースリークするぞ」と考えてはいたよ。
考えてただけで何もしなかったけど。
0304デフォルトの名無しさん
2006/10/02(月) 16:21:43Cは何とか転ばないようにするしかない、という認識しかなかったもので。
実際そういうことを申し渡されると死ぬ思いな気がします。
エラーコードチェックしてばっかだとなんかifばっかで気が滅入ります('д`)
0305デフォルトの名無しさん
2006/10/02(月) 18:54:44これを発明(ｗ)した当時は例外機構なんてｲﾗﾈと思ったね。
f() {
int h = enter(); // a
alloc(h);
g();
alloc(h);
leave(h); // b
}
g() {
int h = enter(); // c
alloc(h);
if (cond)
return ; // error発生
leave(h); // d
}
main() {
int h = enter();
__try { //スレッドの根っこに保険としてSEH
f();
} __finally(cond) {
leave(h);
}
}
aやcでちゃんとleave(h);できなかったらfやmainでまとめて回収する。
longjmpしてもOK(どっかで必ず回収できる事が保障される)。
スレッドごとに必要な場合はTLS使う。
問題はいちいちenter/leave書くのが面倒な事。
0306デフォルトの名無しさん
2006/10/02(月) 19:29:51Symbian OS は全 API/フレームワーク が C++ なんだけど、
言語処理系の例外処理を使わずに自前で例外とunwind 用の
スタックを定義している。
これは ABI やライブラリの互換に縛られずにARMコンパイラとか
gccとか使えるようにするためだと思うけど。
0307デフォルトの名無しさん
2006/10/02(月) 21:45:11C++と比較して、例外安全性を確保するのが容易なのか？
それとも同程度に難しいのか？
0308デフォルトの名無しさん
2006/10/02(月) 21:54:21ちょっとヒドいと思う。ファイナライザがあるとはいえ。
finallyのなかの解放部分をtryで囲むとかヒドス
0309デフォルトの名無しさん
2006/10/02(月) 22:36:040310デフォルトの名無しさん
2006/10/02(月) 22:44:55クラス設計をきちんとやれる(もしくはきちんと設計したライブラリがある)なら
例外安全を意識する回数を減らせる。
ただし finally がないので、ちょっとした後始末をサクっと書けない。
きっちり書くことを強制するのは、むしろ利点だとの主張もある。
Java は 308 氏のに加えて、
チェックする例外とチェックしない例外(C#やC++はこっちだけ)がある。
チェックする例外の場合は try-catch 書かないとコンパイルされないので
よほどのうっかりさんで無ければ例外処理を記述すするものの、記述は非常に煩雑。
素のAPIで記述するとDBアクセスやファイルアクセスは
try-catch で二重三重に囲われて、本来の処理がノイズに紛れる。
ほぼ定型処理なので、フレームワークでうまく切り出して楽に記述できるように工夫する。
(チェックする例外を catch して、チェックしない例外でラップして throw する、なんてことをする。)
C# はチェックしない例外だけ。
ただし using ステートメントを使うと、ブロック内を抜ける際に
Dispose メソッドを呼ぶ。これはC++の「スコープ抜ける時にデストラクタ」みたいな感じ。
Java がかなり特殊で(チェックする例外なんてなくせよって声が小さくない)、
C# が柔軟、C++がガチガチって感じ。
Java は言語仕様・API の粒度が細かいんだと思う。
その代わりライブラリ・フレームワークは充実してる。
(よって1から書くと死ねる。)
0311デフォルトの名無しさん
2006/10/03(火) 00:17:23同様にCの場合の解説も頼むぜ。
0312デフォルトの名無しさん
2006/10/03(火) 00:28:05純粋なCで書いたことってないんで、他にもっと詳しい人にお願いして。
goto 使うとある程度エレガントに記述できるけど
goto 排除原理主義者との戦いが待ってるとか。
0313デフォルトの名無しさん
2006/10/03(火) 10:30:30関数が短けりゃ、飛んでも読むのには苦にならないし。
まーこれは宗教の問題だから、賛成派も反対派も根拠なんてないんだが。
0314デフォルトの名無しさん
2006/10/03(火) 12:52:28goto反対派って原理主義に陥っちゃってるから始末におえない、まさに例外でどっかに飛んでいってほしい
0315デフォルトの名無しさん
2006/10/03(火) 14:25:420316デフォルトの名無しさん
2006/10/03(火) 16:34:520317デフォルトの名無しさん
2006/10/03(火) 18:14:18使ったこと無いし、C標準のライブラリだったかも分かんないな。
0除算とかはキャッチできるらしいけど。
0318デフォルトの名無しさん
2006/10/03(火) 18:26:230319デフォルトの名無しさん
2006/10/03(火) 18:35:330320デフォルトの名無しさん
2006/10/03(火) 18:51:160321デフォルトの名無しさん
2006/10/03(火) 18:52:440322デフォルトの名無しさん
2006/10/03(火) 20:49:310323デフォルトの名無しさん
2006/10/03(火) 20:57:43FILE* fp = fopen("hoge","r");
if(!fp)
{
int i = 0/0;
}
0324デフォルトの名無しさん
2006/10/03(火) 20:58:35例外の無いプログラムを書けばいいだけでは？
0325デフォルトの名無しさん
2006/10/03(火) 21:09:010326デフォルトの名無しさん
2006/10/03(火) 21:10:12なんでそのライブラリ/APIはそういう仕様なの？
と、誘導尋問してみる
0327デフォルトの名無しさん
2006/10/03(火) 21:23:41OOBなイベントの発生を通知したいから。
0328デフォルトの名無しさん
2006/10/03(火) 21:28:37知るか、ヴォケ
0329デフォルトの名無しさん
2006/10/03(火) 22:38:57その論理であらゆる機能を否定していろ。
0330デフォルトの名無しさん
2006/10/03(火) 22:53:33ライブラリ作って
0331デフォルトの名無しさん
2006/10/03(火) 23:35:390332デフォルトの名無しさん
2006/10/03(火) 23:50:43こういう軽快なテキストと掛け合いはもろツボだなぁ
0333332
2006/10/03(火) 23:51:090334デフォルトの名無しさん
2006/10/04(水) 00:40:56何の話か分かってしまう俺はとりあえずthrowされた方がいいですかorz
# いや、ゆのはなはやったことないんだが
0335デフォルトの名無しさん
2006/10/04(水) 00:51:000336デフォルトの名無しさん
2006/10/04(水) 02:03:110337デフォルトの名無しさん
2006/10/04(水) 02:48:01setjmp?
signal?
error?
0338デフォルトの名無しさん
2006/10/04(水) 12:27:03戻り値見て分岐。
0339デフォルトの名無しさん
2006/10/04(水) 16:54:50後処理はどうやるんだ？
0340デフォルトの名無しさん
2006/10/04(水) 20:07:22戻り値見て分岐。
0341デフォルトの名無しさん
2006/10/04(水) 21:12:470342デフォルトの名無しさん
2006/10/04(水) 21:27:41そういう便利なのはないの？
GCライブラリーはあるのに…
0343デフォルトの名無しさん
2006/10/04(水) 21:59:22戻り値見て分岐。
0344デフォルトの名無しさん
2006/10/04(水) 22:38:09#define catch(e) while(0); if (e != 0 )
失敗時に非0を返す戻り値のチェック
意味ねーけどな。
0345デフォルトの名無しさん
2006/10/04(水) 23:12:42__except
__finally
って標準にならないもんかねえ。
0346デフォルトの名無しさん
2006/10/04(水) 23:46:51Subversion の svn_error_t が、かなりがんばってる感じ。
0347デフォルトの名無しさん
2006/10/04(水) 23:56:07Windowsの構造化例外の為だけに標準化するの?
0348デフォルトの名無しさん
2006/10/05(木) 00:07:270349デフォルトの名無しさん
2006/10/05(木) 00:08:51Cで例外があるかないかは天地ほど違うと思う。
0350デフォルトの名無しさん
2006/10/05(木) 00:50:290351デフォルトの名無しさん
2006/10/05(木) 01:29:47try { A } catch (e) { B } finally { C } は、
switch (setjmp(&jmpbuf_table[++sp])) {
case 0: A; break;
default: B;
}
C;
--sp;
throw (e) は longjmp(&jmpbuf_table[sp]); てな感じで。
0352デフォルトの名無しさん
2006/10/05(木) 01:32:020353デフォルトの名無しさん
2006/10/05(木) 11:27:310354デフォルトの名無しさん
2006/10/05(木) 11:41:120355デフォルトの名無しさん
2006/10/07(土) 00:57:38Exceptional C++ Style―40のクイズ形式によるプログラム問題と解法=スタイル編
ハーブ サッター (著), Herb Sutter (原著), 浜田 真理 (翻訳), 浜田 光之
ASIN: 4894714663
出版社: ピアソン・エデュケーション
0356デフォルトの名無しさん
2006/10/07(土) 01:00:050357デフォルトの名無しさん
2006/10/08(日) 14:55:590358デフォルトの名無しさん
2006/10/08(日) 16:20:33仕方ないから、UTF-8に変換して喰わせているんだが、もう少しマトモな方法ないかな？
0359デフォルトの名無しさん
2006/10/08(日) 17:02:06virtual template が使えないしな
規格ではNTBSを返せって話になってるから
NTMBSとかNTWCSとはまた違うんだとは思う
0360デフォルトの名無しさん
2006/10/08(日) 17:37:17map<string,wstring> へのキーを入れるとか。
でも、ファイル名とかの文脈情報を載せる方法を考えないといかんね。
0361デフォルトの名無しさん
2006/10/08(日) 23:34:04いっそのことstd::exceptionのwchar_t版を作ってしまえ。
0362デフォルトの名無しさん
2006/10/09(月) 00:25:360363デフォルトの名無しさん
2006/10/11(水) 03:16:530364デフォルトの名無しさん
2006/10/11(水) 03:20:13ロクに標準化されてないから
不毛なんだよね。
0365デフォルトの名無しさん
2006/10/11(水) 03:42:590366デフォルトの名無しさん
2006/10/11(水) 04:28:48「C、C++はUTF8が標準！！！！」って言っちゃえば良かったのに。
大体、 _t なんてゴミが付いてるのが組み込み型なんて気持ち悪すぎ。
0367デフォルトの名無しさん
2006/10/11(水) 04:30:30沸いてくるのか・・・
面倒だな・・・
0368デフォルトの名無しさん
2006/10/11(水) 04:35:45ユニーク値を投げるのが普通じゃないのか。
>>360もそういう事かな。
0369デフォルトの名無しさん
2006/10/11(水) 04:48:17今でもCは受け入れられているのでないか？
wchar_tやcharを云々言うのは言語Cの話とは関係ないだろう。
0370デフォルトの名無しさん
2006/10/11(水) 19:04:02それいっちゃうと、文字コードの話とかcharとかは
例外処理に関係ないってか、スレ違いっつーか。
0371デフォルトの名無しさん
2006/12/01(金) 22:07:05最近急に例外に興味が沸いてきて本も探してた所なので
名前が挙がってた Exceptional C++ も読むことにする
あと、>>202の言わんとしてるところが、判るようで微妙に判らない
プログラムの実行に支障をきたさないようなエラーって何かおかしい気がするんだけど
日本語のアヤでどこかひっかかってるんだろうか
0372デフォルトの名無しさん
2006/12/01(金) 22:32:18横レスだけど、それって（この例だと）
ファイルが無いときに困りはじめるところで例外を出せってことじゃないの？
一般的にファイルを扱うところ（言われたことをするだけ＝下請け）と
各プログラムでそれを呼び出すところ（元請け）の違いではないかと
あさっての方向だったらゴメン
0373デフォルトの名無しさん
2006/12/02(土) 00:28:040374デフォルトの名無しさん
2006/12/02(土) 01:00:54(一部すっとばすなどして)処理を続行可能な軽微なエラーのことだと思う。
0375デフォルトの名無しさん
2006/12/02(土) 03:46:120376デフォルトの名無しさん
2006/12/02(土) 16:44:200377デフォルトの名無しさん
2006/12/02(土) 20:32:23それはどこのJava/C#ですか？
0378デフォルトの名無しさん
2006/12/02(土) 23:07:34Javaのcharも、C#(CLR)のcharもUTF-8じゃないんだが。
0379デフォルトの名無しさん
2006/12/04(月) 14:57:59くらいかなぁ・・・
後一元管理でスタックトレースをログ保存してるくらいか・・・
0380デフォルトの名無しさん
2006/12/05(火) 00:26:41最近は専らJavaで書いてるけど、この共存状態は
便利さよりも危うさ・不明快さが勝るように感じる。
全部チェックもしくは全部非チェックじゃダメだったんだろうか。
ありえない状態はError投げれば良いし。
100歩譲ってRuntimeExceptionはThrowableから直接派生させるべきだったのでは。
0381デフォルトの名無しさん
2006/12/05(火) 11:25:14全部非チェックにすりゃよかったのに、って意見は多いよな。 後出しだけど。
全部チェックにすると、OutOfMemoryとか常に出る可能性があるからなんかだめぽ。
0382デフォルトの名無しさん
2006/12/05(火) 11:33:460383デフォルトの名無しさん
2006/12/05(火) 23:52:57RuntimeException を作ると言うクラス階層が
生理的に不自然に感じる。
0384デフォルトの名無しさん
2006/12/15(金) 01:15:51FAULTを思いっきりスルーしてくれるから困る。
0385デフォルトの名無しさん
2006/12/19(火) 06:47:460386デフォルトの名無しさん
2006/12/19(火) 07:57:38普通に間違い。
0387デフォルトの名無しさん
2006/12/19(火) 11:01:33そこで例外投げるってのはどうかと思う。
＞例外は、それを取り巻くコードの
＞構造と意味を、根底から覆します。例外は、プログラムの実行時
＞セマンティックを一時的に繋ぎ変え、通常実行しているコードを迂回し、
＞こういう状況でなければ決して実行されないコードを動作させます。
0388デフォルトの名無しさん
2006/12/19(火) 11:45:380389デフォルトの名無しさん
2006/12/19(火) 13:05:360390デフォルトの名無しさん
2006/12/19(火) 15:42:32反省はしない。
0391デフォルトの名無しさん
2006/12/19(火) 18:07:19明らかに復帰不可能な例外なら投げてもいいけど。
0392デフォルトの名無しさん
2006/12/20(水) 01:05:59それが決まってるなら exit() すればいいわけで、例外投げる意味が無い。
0393デフォルトの名無しさん
2006/12/20(水) 01:50:27exit()するとオブジェクトの始末がされないのでは？
0394デフォルトの名無しさん
2006/12/20(水) 10:54:020395デフォルトの名無しさん
2006/12/20(水) 11:05:25ローカルオブジェクトのデストラクタは呼び出されないね。
意味が無いわけじゃないな。
だからといって例外の使い道がそんな場合に限定されるわけじゃないよ。
catch した人が処理を選択できるのが例外の重要な意義なんだから。
>>394
なんでできないと思うの？
0396デフォルトの名無しさん
2006/12/20(水) 11:22:56そんな状態で正常に後始末できるのかなと
0397デフォルトの名無しさん
2006/12/20(水) 13:44:53C++ だと例外安全かどうか気をつかうことになりそうだけどｻ
0398デフォルトの名無しさん
2006/12/20(水) 21:20:00書きたいように書けばいいじゃないか。
0399デフォルトの名無しさん
2006/12/20(水) 21:24:310400デフォルトの名無しさん
2006/12/21(木) 20:21:33これは間違いだと言いたい。
0401デフォルトの名無しさん
2006/12/21(木) 21:30:16何を根拠にそんなことが言える？
0402デフォルトの名無しさん
2006/12/22(金) 15:05:04には別に悪いことはないんじゃない。
ただ、コンストラクタ/デストラクタで例外出すのはやめて欲しいがな
0403デフォルトの名無しさん
2006/12/22(金) 15:09:36コンストラクタは別にいいだろ。他にどうやって失敗を通知するんだ？
0404デフォルトの名無しさん
2006/12/22(金) 15:39:18該当半端ｵﾌﾞｼﾞｪｸﾄの、例外発生前までのうまくいっている部位の後始末をどうするかが面倒
ってことで、問題を簡単化するのに >>402 な希望だと思う
0405デフォルトの名無しさん
2006/12/22(金) 15:57:05それをせずに「コンストラクタから例外禁止」なんて新しいルールを作るのは良くない。
0406デフォルトの名無しさん
2006/12/22(金) 15:58:24後始末が必要なものはクラスで包めばいいじゃん。
0407デフォルトの名無しさん
2006/12/22(金) 16:08:59RAIIが面倒な場合は初期化子リストにtry-catch仕掛けることもできるし
一般にコンストラクタは強い例外安全性を達成するべきという主張なら十分納得できるんだけれど
0408デフォルトの名無しさん
2006/12/22(金) 19:01:16Hoge *hoge; //どっちともコンストラクタで例外を出す可能性があるクラス
Hage *hage;
A()
try:hoge( new Hoge ), hage( new Hage ) { }
catch( ... )
{
初期化子にtry-catch掛けられるったって、こういう状況は非常に面倒くさい。
new Hageで例外でたらどーすんだ？
}
0409デフォルトの名無しさん
2006/12/22(金) 19:23:230410デフォルトの名無しさん
2006/12/22(金) 19:30:10初期化子を使わずにｺﾝﾄﾛｰﾙしろということなのかな？
>>408 の例だと
A()
{
try { hoge = new Hoge; } catch(...) { throw ; }
try { hage = new Hage; } catch(...) { delete hoge; throw ; }
};
0411デフォルトの名無しさん
2006/12/22(金) 19:31:250412デフォルトの名無しさん
2006/12/22(金) 19:36:13{
std::auto_ptr<Hoge> hoge;
std::auto_ptr<Hage> hage;
A() : hoge(new Hoge), hage(new Hage) {}
};
これでどちらで例外が投げられても大丈夫。
0413デフォルトの名無しさん
2006/12/22(金) 19:39:46AのA のﾃﾞｽﾄﾗｸﾀが呼ばれないのは分かるけど、A::hoge と A::hage のﾃﾞｽﾄﾗｸﾀは呼ばれるの？
ｽﾏｰﾄﾎﾟｲﾝﾀって自身のﾃﾞｽﾄﾗｸﾀ呼ばれないと機能しないような気がするのだが
0414デフォルトの名無しさん
2006/12/22(金) 19:49:51コンストラクタが完了したものはデストラクタが呼ばれる。
new Hageで例外が出ても、hogeは構築済みだからデストラクタが呼ばれる。
0415413
2006/12/22(金) 19:57:38てんきゅう。 自分もｺｰﾄﾞ動かして確認した…
例外周りのﾒﾝﾊﾞの取り扱いはややこしいねぇ
実際投げてる例外はおいといてくれｗ
class Hoge {
public:
Hoge() { std::cout << "Construct Hoge" << std::endl; }
~Hoge() { std::cout << "Destruct Hoge" << std::endl; }
};
class Hage {
public:
Hage() { int e=1; throw e; }
};
class A {
std::auto_ptr<Hoge> hoge;
std::auto_ptr<Hage> hage;
public:
A() : hoge(new Hoge), hage(new Hage) {}
};
int main() { try { A a; } catch (...) { } return 0; }
0416デフォルトの名無しさん
2006/12/23(土) 04:53:54構築に失敗したオブジェクトは解体する必要がない
何か気をつける余地が０になるのがRAIIのありがたいところ
0417デフォルトの名無しさん
2006/12/23(土) 12:37:300418デフォルトの名無しさん
2006/12/23(土) 13:45:43それはnew演算子の仕事だよ
0419デフォルトの名無しさん
2006/12/23(土) 14:45:27んーごめん。まったくわからん(´д｀；
0420デフォルトの名無しさん
2006/12/23(土) 14:59:49new Hage の動作を分解すると、
void* storage = operator new (sizeof(Hage));
try { new (storage) Hage; }
catch (...) { operator delete (storage); throw; }
こんな感じになってるわけよ。
0421デフォルトの名無しさん
2006/12/23(土) 16:33:22あざーす
0422デフォルトの名無しさん
2007/01/15(月) 10:20:090423デフォルトの名無しさん
2007/01/15(月) 11:05:00システム内部は全てワイド文字で処理してるプログラムの例外って
みんなどうしてる？
std::exceptionのwhat()ってconst char*しか扱えないじゃない？
そうするとシステム内部のワイド文字列を例外に載せようとした時、
２つの解決方法があると思うんだ。
１つはその文字列をマルチバイト文字列にコンバートして
std::exception（の派生クラス）で投げる。
もう１つはワイド文字列を運べるwexceptionクラスを自作する。
１だと投げる時WCS＞MBS、捕まえて表示するときMBS＞WCSと
無駄な処理が発生する場合がある。
２だとSTLとかが投げる例外と自分のシステムが投げる例外が
同じ処理をする場合でも、いちいちcatch節を２つ書かなきゃならない。
まあ例外は全てMBSで扱って表示もMBSでしかしないってのもアリだけど
0424デフォルトの名無しさん
2007/01/15(月) 11:44:20int id,
wchar *hoge;
} what;
exception((char *)w);
0425デフォルトの名無しさん
2007/01/15(月) 12:19:320426デフォルトの名無しさん
2007/01/15(月) 13:06:57一番堅いけれど面倒なやり方として，
エラーの識別子のみを std::exception に載せる std::string の情報とする扱い方．
エラーを人間に読めるようなメッセージに変換する必要があるならば，
メッセージカタログなりを使ってエラーの識別子とエラーメッセージとの対応を取る．
この場合，表示するメッセージを MBS とするか WCS とするかのポリシーは
メッセージカタログの責任範疇となって， std::exception と独立となるのが利点．
0427デフォルトの名無しさん
2007/01/15(月) 20:08:02std::exceptionにstd::stringに埋めちゃうのは、std::stringのコピーコンストラクタ
が例外を発射する可能性があるから、やばいのでは。
例外処理の運用については、>>423的な悩みも含めて Boost の
http://www.boost.org/more/error_handling.html がとてもよくまとまっていると思う。
(翻訳版はバージョンが古いのか、内容が違う)
あとはexception safty(例外安全性(?))やexception neutral (例外中立性(?))
なクラスの設計、実装について、Exceptional C++, More Exceptional C++,
Exceptional C++ Style の該当項目に目を通せばOK。
0428426
2007/01/15(月) 22:01:37＞std::exceptionにstd::stringに埋めちゃうのは、std::stringのコピーコンストラクタ
＞が例外を発射する可能性があるから、やばいのでは。
この問題は完全に見落としていました． newsgroup などを漁った感じでは
std::exception の設計・実装の一部にも問題があるといえる状況のように感じます．
http://tinyurl.com/y7c2wu
＞http://www.boost.org/more/error_handling.html
自分が426で書いたことは "How should I design my exception classes?" の
5に書いてあることにおおよそ対応しますね．
というか，そもそも426で書いた内容は Peter Dimov 氏の受け売りでしかないですけれど．
http://tinyurl.com/umvgh
0429423
2007/01/15(月) 22:06:59Win32APIのGetLastError()とFormatMessage()みたいなことかな。
できれば問題が起きた原因たるオブジェクト（の内容）を
例外ハンドリングしてるところまで持ってって表示してあげたいんだけど、
その方法じゃ無理だね。困った。
>>427
つまり↑みたいな野望は無駄な足掻きってことかな…。
staticなエラーメッセージ保存領域作っておいて
そこにコピーしてから例外飛ばすとか？
てか、もしかしたら例外で処理すべき問題じゃないのかもしれない…
0430デフォルトの名無しさん
2007/01/16(火) 08:01:01規格にある std::exception::what() についての記述には、
wstring に変換して表示するのに適した NTMBS でもよい、とある。
規格に沿うようにしたいのなら、このアプローチがいいってことね。
0431デフォルトの名無しさん
2007/01/16(火) 11:47:14>Win32APIのGetLastError()とFormatMessage()みたいなことかな。
みたいなことですね。
>できれば問題が起きた原因たるオブジェクト（の内容）を
>例外ハンドリングしてるところまで持ってって表示してあげたいんだけど、
エラーの文脈情報を付加したいという話ですよね。そのエラーに対応する
std::exceptionの派生クラスのメンバ変数に持たせれば可能なのでは。
>>>427
>つまり↑みたいな野望は無駄な足掻きってことかな…。
いや、427ではstd::exceptionにstd::stringを「埋める」とやばいという話を
しましたけど、ポインタで（例えばstd::auto_ptr<std::string>)で持たせれば
問題はありません。string以外の文脈情報についても同様です。
0432デフォルトの名無しさん
2007/01/16(火) 17:03:340433デフォルトの名無しさん
2007/01/16(火) 18:27:19例外クラスの設計で注意しなきゃいけないのは、スタックの巻き戻しを
している最中に呼ばれる例外クラスのコピーコンストラクタが例外を
発射しないことです。
この状況になると通常、terminate()直行で、どこのエラーで落ちたのか
もわからない結果になります。
それ以外の状況なら例外処理中に例外が発生しても対処は可能でしょう。
0434デフォルトの名無しさん
2007/02/22(木) 01:00:41信頼性に関するベスト プラクティス
http://msdn2.microsoft.com/ja-jp/library/ms228970(VS.80).aspx
■ このスレッドは過去ログ倉庫に格納されています