エラーチェックがめんどくさい
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
NGNGいちいち関数の戻り値とかチェックしてるときりがない。
おまえらはどうよ。
0002デフォルトの名無しさん
NGNGトレンドは例外・実行時エラーをキャッチだろ。
0003デフォルトの名無しさん
NGNG00041
NGNGおお、正解
0005デフォルトの名無しさん
NGNG例外は事前準備が面倒なんだよなぁ。
MFC使う場合は AfxUserException()、C++一般の
場合はSTLの例外クラスを派生させて
使うのが一般的なの？
0006デフォルトの名無しさん
NGNGセキュリティホールになりかねないからヤバい
それ以外は仕様ですませれ
0007デフォルトの名無しさん
NGNG学生? 社会に出るまでに考えなおせよ。
そんな無責任ではプログラマに限らず商売できんぞ。
セキュリティホールもremote exploitableなものに限らんし。
0008デフォルトの名無しさん
NGNG0009デフォルトの名無しさん
NGNG0010デフォルトの名無しさん
NGNG0011デフォルトの名無しさん
NGNGトレンドなんですか？
0012デフォルトの名無しさん
NGNG俺の場合名前だけ付けた空クラスとか空構造体にする
0013デフォルトの名無しさん
NGNG>>11には小人さんの幻覚でも見えるんだろうか？
0014柳沢
NGNGもちろんｽﾙｰ
昨日はヘッドで決めてやったけどな
0015デフォルトの名無しさん
NGNG0016デフォルトの名無しさん
NGNGエラーチェック関数を作れ！
例外はTry Catchなどのクラスを使え！
エラーチェックはプログラムを作る最低限の常識
面倒って言うなら、エラーが出ないように作れ！
だか、ユーザーはどんな行動をおこすか不明だから、
エラーが出ないようにするのは不可能！
よって、仕様レベルでどこまでエラーチェックするかどうかって事だ！
クソスレ立てるなYo。だから氏ね
0017デフォルトの名無しさん
NGNG制御構造じゃなくて
0018デフォルトの名無しさん
NGNG0019デフォルトの名無しさん
NGNG0020デフォルトの名無しさん
NGNGA girl
0021デフォルトの名無しさん
NGNGなんのことやらわからなかったり。
0022デフォルトの名無しさん
NGNG0023デフォルトの名無しさん
NGNG0024デフォルトの名無しさん
NGNGシステムをやられてしまうこともありませんよ
0025デフォルトの名無しさん
NGNGアプリとかでメモリリークが深刻な問題になっていく
0026デフォルトの名無しさん
NGNG0027デフォルトの名無しさん
NGNGおまいは読解力ゼロか？
別にVBが駄目と言ってるんじゃない。
それを使う奴の問題意識の話だ。
0028デフォルトの名無しさん
NGNGデータベースセッションとかセッション系などは開放されねぇよ！
うすら禿げ！
いいかげんなこと言うな！
0029デフォルトの名無しさん
NGNG0030デフォルトの名無しさん
NGNGメモリの解放としかいってないだろ。
003128
NGNGサーバーにもクライアントにもメモリに残ってしまいますよ。
>>24さんは、
VBだとメモリの開放も自動でやってくれて…って述べてまふ。
うすら禿げ！はいい過ぎですた。スマソ。
0032デフォルトの名無しさん
NGNG主語がねーぞｗ
0033デフォルトの名無しさん
NGNG0034デフォルトの名無しさん
NGNG頼むから殴らな○▽※♂♀
0035デフォルトの名無しさん
NGNGC++は例外使うとメモリリークが怖いよなぁ。
これを避けるためにコンストラクタで資源確保
とか言われてるけど、かなーり手間だと思うんだが。
0036デフォルトの名無しさん
NGNGKeBugCheck()させて、ぼかーん
0037デフォルトの名無しさん
NGNGInitとかCreateといった名前の関数を作って、初期化はそこでやる。
もちろん解放もデストラクタではなく、解放用の関数を作って明示的に呼ぶ。
0038デフォルトの名無しさん
NGNG0039デフォルトの名無しさん
NGNG0040デフォルトの名無しさん
NGNG漏れは>>37派なわけだが
0041デフォルトの名無しさん
NGNGＣ＋＋でnewつかうとバグするプログラムで、
Win32APIのメモリ関数にしたら、バグらなくなった。
0042デフォルトの名無しさん
NGNG千差万別。結局のところソースを見ないと解決しない。
ソースをうｐしてみれ。
0043デフォルトの名無しさん
NGNGバグらなくても、そういうのは、
なんとなくこわいな。（ｗ
0044デフォルトの名無しさん
NGNG> Win32APIのメモリ関数にしたら、バグらなくなった。
この主張がまず意味不明。
0045デフォルトの名無しさん
NGNG0046デフォルトの名無しさん
NGNG0047デフォルトの名無しさん
NGNG理由もなしに俺ルールつくんなよ。
0048デフォルトの名無しさん
NGNG0049デフォルトの名無しさん
NGNG明示的に呼ぶこともできるようにして。
0050デフォルトの名無しさん
NGNG何のためにprotectedやprivateがあると思ってんだ？
もし、>>47-48がマジレスしてるのであれば哀れだぞ。
そうでない事を祈る。当然、釣りだよな？
0051デフォルトの名無しさん
NGNG0052デフォルトの名無しさん
NGNGそんなもんここでは全く関係ない話。
0053デフォルトの名無しさん
NGNG0055デフォルトの名無しさん
NGNG遠まわしに言わないで直接言ってくれよ。
0056デフォルトの名無しさん
NGNG0057デフォルトの名無しさん
NGNG0058デフォルトの名無しさん
NGNG0059デフォルトの名無しさん
NGNG0060デフォルトの名無しさん
NGNG0061デフォルトの名無しさん
NGNG言っている人は例外の正しい使い方を知らないんだよ。
コンストラクタで資源確保して何がいけないの？と聞けばすぐわかる。
変なことしか言えないか、答えられないかのどちらかしかない。
さてなんて答えるか聞いてみよう。答えてね。>>50
> データトレースすべき位置を絞り込む
> 効果も期待できるって事が判らんのか？
なにを絞り込めるんだかｗ
エラーが発生する個所が移動するだけじゃん。
それからアサートって知ってるか？ｗ
0062デフォルトの名無しさん
NGNGナムコから出てた2レバーのやつですね。
0063デフォルトの名無しさん
NGNG0064デフォルトの名無しさん
NGNGおまいさんが言いたいのはコンストラクタで資源確保に失敗しても
例外を投げればエラーに対処できるってことか？
残念ながら場合によっては悲惨なことになるぞ。
コンストラクタで二つ以上の資源確保するとするよな。
一つ目は無事成功、二つ目で確保失敗して、例外ハンドラに制御が移る。
そうすると一つ目の方の資源解放ができんわけだ。
目的のクラスも作られなかったわけだから、デストラクタもdeleteも無理。
で、めでたくメモリリークだ。わかるか？
0065デフォルトの名無しさん
NGNG0066デフォルトの名無しさん
NGNGtry : A()/*may be throw*/, B() {
try {
initialize(); /* may be throw*/
}
catch(...) {
cleanup();
throw;
}
}
catch (..) {
cleanup();
}
こんな感じじゃダメなのか？
0067デフォルトの名無しさん
NGNG複数の資源を単一のオブジェクトで管理しようとするのがアフォ。
0068デフォルトの名無しさん
NGNGｽﾏｿ、それでいけるな
例外についてわかってないのは漏れでした
0069デフォルトの名無しさん
NGNGスマートポインタみたいなの(要は、個々の資源の確保と解放に責任を持つ物)を
メンバーにするやり方がよろしい。
と、More Effective C++に書いてあった。
なぜイマイチよろしくないのかは、
忘れた。
0070デフォルトの名無しさん
NGNG例外の発生原因はメモリ確保だけじゃないですよ
というか、>>66がよくないのはMore Effective C++が執筆された当時
まともにサポートしてるコンパイラがあまり無かったからだろう
0071デフォルトの名無しさん
NGNG例外が発生したときに資源を解放できないことが問題なんだろ？
例外の原因がメモリ確保にあるかどうかなど関係ない。
それに解放すべき「資源」がメモリだけではないのも当然。
0072デフォルトの名無しさん
NGNGコンストラクタの途中で例外が発生しても(←何故か例外の発生げいいんを問題にする奴もいる)
メンバーが確保(しようと)している資源をリークさせず確実に解放するために
スマートポインタを使い、fstreamを使う。
0073デフォルトの名無しさん
NGNG0074デフォルトの名無しさん
NGNGhttp://that.2ch.net/test/read.cgi/gline/1074839941/
0075デフォルトの名無しさん
NGNGちょっと見たことない形だし
>>70の言葉からしてもなんか特殊な構文なのかな？
だとしたら俺の勘違い。
More Effective C++で触れられているのは
・constなポインタ等、コンストラクタの初期化リストで初期化したい
・そのためには別のinit()とcleanup()が必要
・さらに、複数のメンバーの確保順を把握しながら、確保/例外/解放処理を書く必要があるため
保守上の問題がある
が理由として挙げられている。
実際、こんなクラスにメンバーを追加したりするのは、俺も嫌。
そこで、「初期化されたメンバーのデストラクタが必ず呼ばれる」事を利用した
資源の確保/解放専用クラス(スマートポインタ等を含む)を利用すべき
となる。
0076デフォルトの名無しさん
NGNG良いということが前提になって話がすすんでいるな。
いや、まあ当然のことなんだけど。
んでコンストラクタで例外が発生した場合に
資源を管理しやすくするためにスマートポインタ等を使えと。
0077デフォルトの名無しさん
NGNG「例外スローすりゃ綺麗！！」程度の認識で
クラスを作られては、たまらんよ。
作った本人は自己陶酔に浸れていいかもしれんが、
他人がそれを２次利用する事をちゃんと想定しているのかな？
0078デフォルトの名無しさん
NGNGなにに苦しめられたの？
エラー番号チェックから例外に変わっているだけでも便利だと思うけど。
0079デフォルトの名無しさん
NGNG0080デフォルトの名無しさん
NGNG>なにに苦しめられたの？
ハンガリー記法
0081デフォルトの名無しさん
NGNG0082デフォルトの名無しさん
NGNG全くそうでないところとかあったりするよな。
0083デフォルトの名無しさん
NGNGboost::scoped_ptr あたり使っとけば、特に何もしなくてよろしいということでしょうか？
0084デフォルトの名無しさん
NGNGなんだ。ただの変数名のルールに苦しめられたのか。
俺はてっきり例外あちこちに飛んで意味分からん。
戻り値チェックでいいじゃん。
とか低レベルなこと言うつもりなのかと思ったよ。
0085デフォルトの名無しさん
NGNG>なにに苦しめられたの？
lpsz
0086デフォルトの名無しさん
NGNGぱっと見で、throw()指定とも違うし
なんとなく初期化リストでの初期化時の例外をcatchしてるように見えるけど
>>70はわかってるっぽいし
出来たらちゃんとコンパイルできる形式でのサンプル希望
0087デフォルトの名無しさん
NGNGウチはVC6だからか、コンパイルすら通らないけど
0088デフォルトの名無しさん
NGNG0090デフォルトの名無しさん
NGNGstruct A
{
A(int i) { throw i; }
};
struct B
{
const A a;
B() try : a(0) {
}
catch (int i) {
std::cout << i << std::endl;
}
};
int main()
{
try {
B b;
}
catch (int i) {
return i;
}
return 0;
}
これで通った(gcc3.3.1)
009188=75
NGNGhttp://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/jpdndeepc/htm/deep102199.asp
009288=75
NGNGかなり後に構文が追加されたとなっているので
今のところgcc3.3とかVC7とかじゃないと動かないのかな。
複数メンバーの初期化時の個別catchとか、調べてみたいこともいろいろあるけど
実際に常用環境を移行するようになってから試してみるようにする。
どうもありがとう。
0093デフォルトの名無しさん
NGNG0094デフォルトの名無しさん
NGNG0095デフォルトの名無しさん
NGNG0096デフォルトの名無しさん
NGNGある意味正しい。C++はなんでも出来てしまう。
コーディング規約を意図的に作らない限り、泥沼に入る言語だ。
だが、C++を否定しようとするヤシは、C++に負けたヤシだとも言える。
C・C++プログラマからすれば、こういうヤシは失笑モノだ。
心底C++を否定したいヤシもいるかもしれんが、
人前では言わない方がいい。
「あぁ、コイツはその程度か」と思われるだけだからだ。
0097デフォルトの名無しさん
NGNG0098デフォルトの名無しさん
NGNG例の禿げが、Ｃ++の否定したらしい話があるらしいけど、ホントだったらどうするよ？
0099デフォルトの名無しさん
NGNG流出ソースのカトラーたんの署名があったソースは全部Cだったらしいし
0100デフォルトの名無しさん
NGNG無駄なスキルだわな。。。そんなスキル自慢されてもねぇ。
つーか、Cまで一緒にすんな。
0101デフォルトの名無しさん
NGNG>>96 が失笑を買っています。
0102デフォルトの名無しさん
NGNGどっかのサイト(URLに"joke"が含まれてた)に載ってたな
0103デフォルトの名無しさん
NGNG─、、
（ﾟ皿ﾟ Ｏ） ガオー！
/￣/ >>
|￣| | |
@/＼ ＼@/
/'/ /'/
| | | |
-┛ -┛
0104デフォルトの名無しさん
NGNGいつの間にかメタモルフォーゼしてるし。
ここまで変えるなら、言語ごと変えた方がいいだろとか思ったり。
tryキーワードを付ける意味ねー。やっぱC++ｳｾﾞぇ
0105デフォルトの名無しさん
NGNGBjarne Stroustrup Interview about C++
これ？
0106デフォルトの名無しさん
NGNG0107デフォルトの名無しさん
NGNGついバレンタイン数日前に振られたあげく、13日に家に帰ってきたら義理チョコが家においってあってかなり凹みましたが何か？
さっさと荷物かたづけてかぎかえしやがれってんだ。
0108デフォルトの名無しさん
NGNG> 家においってあって
ここのところの説明をお願いします。
0109デフォルトの名無しさん
NGNG疲れてたから、単なる誤字だ。せいぜい警告程度だろうが
0110デフォルトの名無しさん
NGNG0111デフォルトの名無しさん
NGNGつける意味はあるんじゃないのか？
スマートかどうかはともかくとして。
0112デフォルトの名無しさん
NGNG0113デフォルトの名無しさん
NGNGあるんだがこれにC++の仕様全部書いてあるよな？
0114デフォルトの名無しさん
NGNG書いてない。
0115デフォルトの名無しさん
NGNGうちにもあるけど、だいたい網羅してると思うが。
ただ読みにくいね。何章も前の例題を後の章で
引きずってるから、拾い読みができない。
0116デフォルトの名無しさん
NGNG書いてない仕様を教えてくれ。
0117デフォルトの名無しさん
NGNG0118デフォルトの名無しさん
NGNGあるんだがこれにC++の仕様全部書いてあるよな？
0119デフォルトの名無しさん
NGNGC++の仕様を覚える必要などナシ！
そんな事よりも藻前のコンパイラが吐く警告・エラーに対処しろ。
ANSIC++完全準拠コンパイラなど存在しない。
0120デフォルトの名無しさん
NGNG鼻から何か飛び出してから慌てるのもあれなんで、未定義になるコードの例を
いくつか覚えておくといい。
0121デフォルトの名無しさん
NGNGおいおい。覚えないために本があるんだろ。
0122デフォルトの名無しさん
NGNG>>121
> おい。俺んちには「プログラミング言語 C++ 第三版」が
この本は規格書ではない。
特にテンプレート周りは規格書をみないとわからないことが多い。
0123デフォルトの名無しさん
NGNG0124デフォルトの名無しさん
NGNG0125デフォルトの名無しさん
NGNGエラーチェックなんぞしない。
0126デフォルトの名無しさん
NGNGエラーチェックをするんだろうがよ
0127デフォルトの名無しさん
NGNG0128デフォルトの名無しさん
NGNG0129デフォルトの名無しさん
NGNGクラスの作り方も知らないからこうなるんだよ(ﾜﾗ
0130デフォルトの名無しさん
NGNG作らない 作らせない 持ち込ませない
0131デフォルトの名無しさん
NGNGエラーを出す前にコケるそうです。
0132デフォルトの名無しさん
NGNG普通のアプリケーション作ってて、対処しなければならないエラー処理って
>>126のようなAPIの戻り値ぐらいじゃん。
こんなのって復旧のしようが無いよ。
結局そのまま上に例外をスルーさせるか、エラーメッセージだして強制終了させる
ぐらいしか出来ない。
0133デフォルトの名無しさん
NGNG> 結局そのまま上に例外をスルーさせるか、エラーメッセージだして強制終了させる
それも十分な使い道じゃん。
いちいちエラーコードチェックしなくて良いんだし。
0134デフォルトの名無しさん
NGNGエラーコードチェックしなけりゃ問題だろ。
手抜きプログラムだ
0135デフォルトの名無しさん
NGNGエラーのチェックはしても、いちいちする必要は無いじゃん。
tryブロックの中で発生した例外は皆同じ catch に行くんだし。
ファイルの入出力とかの時便利よ。
0136デフォルトの名無しさん
NGNGやはり手抜きじゃないか。
エラーってのは、こう慎重にな、何が悪いのか、ちゃんと
エラー復旧処理はちゃんとできるのか、エラーが起きたときの情報を
ちゃんと得られるのかってとっても丁寧にやらなきゃいけないんだぞ。
皆同じcatchにいってそれができるのか？
エラーが起きたときのファイル名とかちゃんと取得できるのか？
0137デフォルトの名無しさん
NGNGある関数の中で、あるルーチンAが実行時エラーを起こしたので
例外を投げて別のルーチンBで処理した。
みたいなことやれたらスマートだと思うんだなあ。
0138デフォルトの名無しさん
NGNGファイル名（や他の情報）が欲しければそれが取れる位置にcatchを書くか
例外オブジェクトに持たせればよいと思いまつ。
0139デフォルトの名無しさん
NGNGcatch でルーチンBを呼び出すのではいかんの？
俺もCFileで、ファイルがないくらいで例外投げるのマンドクセと
思ってたけど、最近は PathFileExists でファイルを確認してから
開くようにしてるので、CFileも tryブロックで囲まなくなった。
0140デフォルトの名無しさん
NGNG0141デフォルトの名無しさん
NGNGおい。PathFileExistsでファイルを確認した後で
ファイルがなくなったらどうするんだ！？
0142デフォルトの名無しさん
NGNG以上。
0143デフォルトの名無しさん
NGNGマルチタスク環境の経験ないの? DOS?
0144デフォルトの名無しさん
NGNG馬鹿ですか？ 糞ルールつくんな。禿げ。
0145デフォルトの名無しさん
NGNGそんな稀なケースまで考慮する必要あるかなぁ？
マルチタスクだから理屈としてはあり得る話だけど。
0146デフォルトの名無しさん
NGNGそういうのが稀じゃなく起こる仕事もあるってことさ。
0147デフォルトの名無しさん
NGNG0148デフォルトの名無しさん
NGNG少なくともドライバでは使い道があるぞ。
ブルースクリーンを回避できるからな。
0149デフォルトの名無しさん
NGNGなるほど。
それじゃ try 使うしかないか。
0150デフォルトの名無しさん
NGNGエラー値で判断すりゃ良いじゃん。
0151デフォルトの名無しさん
NGNG（ ´∀｀）＜ ぬるぽ
0152デフォルトの名無しさん
NGNGdo {
セルフサービス；
} while (1);
0153デフォルトの名無しさん
NGNG∧＿∧
（ ´∀｀）＜ ぬるぽ
} while (1);
0155154
NGNG0156デフォルトの名無しさん
NGNGMFCで使う場合の例外って、１つはSTLで使われる
exception とその派生クラスの例外と、もう１つは
MFCのCException とその派生クラスの2系統が
あるんだっけ？
例外を派生させなくてもいいという意見もあるけど、
基底クラスでcatchすることを考えると、やっぱ
派生させて構造化した方がいいと思うんだけど、
あんまり解説してる本多くないんだよな。
0157デフォルトの名無しさん
NGNGお前らはエラーチェック面倒くさいの? どうなの?
0158デフォルトの名無しさん
NGNGエラーチェックするのはコンピュータだから、俺は面倒だとは思わない。
0159デフォルトの名無しさん
NGNG0160デフォルトの名無しさん
NGNGエラーチェックは面倒くさくないが、
起こってしまったエラーのリカバリの
扱いはめんどくさい。
0161デフォルトの名無しさん
NGNG好きな型を返せるってのはダメ？
0162デフォルトの名無しさん
NGNGtry {
FILE* fp = fopen("abc.txt", "r");
if (fp == NULL)
throw exception();
} catch (...) { }
これじゃエラーチェックしてgotoしてるのと変わらんし。
try {
FILE* fp = my_fopen_with_exception("abc.txt", "r");
} catch (...) { }
これだといちいち関数作らないとならないし。
出来合いのものといっても、事実上boostしか標準的な選択肢が存在しないからな。
0163デフォルトの名無しさん
NGNGfopenは直接使う機会が多そうだけど
ヒープメモリとかはどうよ。
エラー判定を内包する事が多いんじゃないか？
obj create(size) {
void *r = malloc(size);
if (!r) throw badallocate;
return (obj)r;
}
0164デフォルトの名無しさん
NGNG> >>95
> ある意味正しい。C++はなんでも出来てしまう。
> コーディング規約を意図的に作らない限り、泥沼に入る言語だ。
>
> だが、C++を否定しようとするヤシは、C++に負けたヤシだとも言える。
> C・C++プログラマからすれば、こういうヤシは失笑モノだ。
>
> 心底C++を否定したいヤシもいるかもしれんが、
> 人前では言わない方がいい。
> 「あぁ、コイツはその程度か」と思われるだけだからだ。
それはCOBOLを否定されたCOBOLerが僻みと同じだろうよ。
吾輩は人前ではよくいう。
だが、全面否定はしない。「こういうことするにはC++のこの部分が〜悪い」
という言い方で否定しているにすぎない。
全面否定してしまっていてはOSにC++を使ってはいけないと言うことになり、
数々のOSを否定することになるからだ。
0165デフォルトの名無しさん
NGNG> >>106
> ついバレンタイン数日前に振られたあげく、13日に家に帰ってきたら義理チョコが家においってあってかなり凹みましたが何か？
> さっさと荷物かたづけてかぎかえしやがれってんだ。
そのうちその女の悪友に鍵のコピーが回って泥棒に入られるぞ。
鍵をコピーされているかもしれんから。
今のうちに錠前も別のものにしておけ。
0166デフォルトの名無しさん
NGNGC++で例外にすら対応していない旧式のCの関数使っているからじゃんｗ
0167デフォルトの名無しさん
NGNGそんなあなたにアスペクト指向。
0168デフォルトの名無しさん
NGNG別にfopenに意味があるわけじゃないから、
fopenじゃ無くてOSのシステムコールでもいいんだけどね。
分かりにくい例を出しても仕方ないし。
0169デフォルトの名無しさん
NGNGVCでは__LINE__と__FILE__マクロが使えるけど。
0170デフォルトの名無しさん
NGNG0171デフォルトの名無しさん
NGNG他のとこの発生場所ってわかるの？
デバッグ情報使わない？
0172デフォルトの名無しさん
NGNGC++で例外にすら対応していない旧式のOSのシステムコールを使っているからじゃんｗ
WinFXのような例外に対応しているOSのシステムコールなら無問題
0173デフォルトの名無しさん
NGNGあっそ、それでおまえはWinFX使ってるわけだ
0174デフォルトの名無しさん
NGNG正式リリースしてないのに使っているわけ無いじゃん。
でも例外に対応しているので無問題なのは確かですよ。
0175デフォルトの名無しさん
NGNGC言語は例外を使えない。
C言語が使えないOSはOSと認められない。
ゆえにWinFXがAPIであるLonghornはOSとは認められない。
0176デフォルトの名無しさん
NGNG別に、MS独自マクロではない。ANSI-Cマクロ。
但し、__FILE__は展開されるファイル文字列の仕様が
まちまちなので（ファイル名orフルパス名など）注意。
0177デフォルトの名無しさん
NGNGOSが独自の例外機構をもっていることとC++言語が対応していることは等価ではないよ
Win32のSEHは、VC++を使えば捕捉できるけど、BCでは捕捉できない。
それにWinFXはManagedC++以外でも使えるのか？
オブジェクト型とか既存のC++と互換性があって、実装も互換性が有るの？
0178デフォルトの名無しさん
NGNGC++はCを包含している。従って、
「C言語が使えない」
という表現自体がありえない。
0179デフォルトの名無しさん
NGNGC言語でどうやって例外を扱うのでしょうか？ｗ
0180デフォルトの名無しさん
NGNG現実を見ようよ
0181デフォルトの名無しさん
NGNGC++はCを包含しているために、
C++を使えばCで例外を使用できる。
と。C++を使えば・・・あれ？（激藁
0182デフォルトの名無しさん
NGNG0183デフォルトの名無しさん
NGNG0184デフォルトの名無しさん
NGNG別にいいんでわ？
わざわざインアセ使うところを拡張構文にしてすっきりさせてるんだし。
0185デフォルトの名無しさん
NGNG0186デフォルトの名無しさん
NGNG0187デフォルトの名無しさん
NGNG既存のC++とか言っている意味が良く分からんけど、
C++に使用できる外部ライブラリの形式(.dllとか.oとか)の
規定があったか？
外部ライブラリがあってそれをどうサポートするかは処理系次第だろ。
0188187
NGNG外部ライブラリがあってそれをどうサポートするかは
元から処理系次第だろ。
0189デフォルトの名無しさん
NGNGWindwosだとちょーめんどくさくね？
逆にlinuxとかだと実行ファイルのパス名取得する程度の事が
ちょーめんどくさい。
OS文化が違うんだな。
0190デフォルトの名無しさん
NGNGgoto も使えた方がいいけど、
java みたいに break と continue にラベルを指定
できるともっといいな。
0191デフォルトの名無しさん
NGNGでもgccはgasがｷﾓｲ。
世の中うまくいかんね。
0192デフォルトの名無しさん
NGNGこういうのが好きだ。大好きだ。
0193デフォルトの名無しさん
NGNG２０年前に生まれてればよかったね
0194デフォルトの名無しさん
NGNGえ？20年前に生まれたら、今年20才。
(´∀`)「C#をアカデミックパックで覚えますた。」
とか言い出しそうだ。
0195デフォルトの名無しさん
NGNGご自分のお歳を＋２０加算してください
0196デフォルトの名無しさん
NGNG0197デフォルトの名無しさん
NGNG「２０年早く生まれていれば良かったね」
になっていないのが悪いな。
0198デフォルトの名無しさん
NGNG0199デフォルトの名無しさん
NGNGゼロとなる位置が初期化されてなかった事が問題だな。
ゼロ位置に何が入るかは、文章を読む人に依存してしまうので、
ランタイムエラー。
int main()
{
int pos;
pos -= 20;
printf("%d\n", pos);
return 0;
}
0200デフォルトの名無しさん
NGNGわかりづらすぎ
0201デフォルトの名無しさん
NGNG自分の勘違いが結論ですか？ｗ
0202デフォルトの名無しさん
NGNG0203デフォルトの名無しさん
NGNG0204デフォルトの名無しさん
NGNGtry {
例外が発生した行
} catch {
処理
}
次の行
0205デフォルトの名無しさん
NGNG0206デフォルトの名無しさん
NGNG予測に対処するという意味で使用するならわかるんだが、
どーもそうではないような書き込みが。
0207デフォルトの名無しさん
NGNGExceptionがthrowされるのは別に＊例外的＊なことじゃなくて、
エラーが起きた場合だってだけなのに。
try ... catch の catch節に書くのは＊予測＊されたエラーの処理だ。
いちいち戻り値をチェックするのが面倒だからException使うんじゃん。
0208デフォルトの名無しさん
NGNGそのなかでも復旧可能なものが Exception で不可能なものが Error だと
(俺は) 思っている。
>いちいち戻り値をチェックするのが面倒だからException使うんじゃん。
これは同意するが
>try ... catch の catch節に書くのは＊予測＊されたエラーの処理だ。
これは同意しない。
「例外的」という言葉と「予測」という言葉は別に直交しない。
0209デフォルトの名無しさん
NGNG制御乱してどうすんだよ
復旧できるならその場で復旧すべきだろ
設計したやつは頭悪いね
0210デフォルトの名無しさん
NGNG>復旧できるならその場で復旧すべきだろ
その通り。
例外機構はその場で復旧できないエラーを処理するために在る。
0211デフォルトの名無しさん
NGNGたとえばデータベースへの接続。
接続する前に接続に失敗するかどうかなんてわからん。
それに接続に失敗したら、画面に必ず接続に失敗しましたと表示される
connect()関数なんて使いたくないぞ。エラー結果を親に返すのは当然だろ。
0212デフォルトの名無しさん
NGNG0213デフォルトの名無しさん
NGNGその通り。
0214デフォルトの名無しさん
NGNG戻り値をエラー以外に使えなくなっちゃ苦からなぁ。
なんかの値を返す関数の内部でエラーを返す関数を
使うだけでもう破綻してしまう。
0215デフォルトの名無しさん
NGNG・・・そういう問題じゃないな。
Cとかの場合は引数側にポインタ渡しで出力するよね。
あれがいまいち気に食わない。
in|out|inoutをソースコードとは別にドキュメント化しないといけないし。
0216デフォルトの名無しさん
NGNG全部かどうか忘れたけど、ほとんどそうだったような…
これはこれで好きなんだけどなー。
0217デフォルトの名無しさん
NGNGreturn values(1,2);
}
main() {
int a,b;
receive(a,b) from f();
printf("a=%d, b=%d\n",a,b);
}
うぐぅ・・
0218デフォルトの名無しさん
NGNG必要な値を返す戻り値は引数になっている。
もちろん他の言語からは、エラーは例外になって
必要な値が戻り値に変換されるが。
0219デフォルトの名無しさん
NGNGinとout/inoutはconstをつけるかどうかで明示できるけど
outとinoutの識別は難しいな。C++なら、
template <typename T>
struct Out_ptr {
struct ref {
ref(T &r):r(r){}
operator=(const T &t){r=t;}
T &r;
};
ref operator*(){return ref(*p);}
T *p;
};
こういうので何とかならないこともないが。
0220デフォルトの名無しさん
NGNGちゃんとprintfのエラー処理しろよ。
エラーが起きたのに処理続行されても良いのか？
0221デフォルトの名無しさん
NGNG良いからサボるわけで。
0222デフォルトの名無しさん
NGNGそれはエラーが起きても無反応で良いということか？
エラーが起きたらデフォでエラーメッセージが表示される方がいいだろ。
0223デフォルトの名無しさん
NGNGよくなかったらサボらないわけで。
0224デフォルトの名無しさん
NGNG0225デフォルトの名無しさん
NGNG場合によるね。
0226デフォルトの名無しさん
NGNG0227デフォルトの名無しさん
NGNGといっているのと同じだよ。>>226
0228デフォルトの名無しさん
NGNG0229デフォルトの名無しさん
NGNG禿同。戻り値厨はデフォの違いの重要性を理解してないんだよなぁ。
フェイルセーフってやつだ。
0230デフォルトの名無しさん
NGNGなにこれw
0231デフォルトの名無しさん
NGNG戻り値
成功すると，printf は出力バイト数を返します。
エラーの場合は，printf は EOF を返します。
0232デフォルトの名無しさん
NGNGお、そだね。ｺﾞﾒﾝ。
0233デフォルトの名無しさん
NGNG返却値と呼びましょう。
0234デフォルトの名無しさん
NGNGお前だけだよ。そう読んでいるのは。
0235デフォルトの名無しさん
NGNG0236デフォルトの名無しさん
NGNGerrnoとか関係なく問答無用で落ちない？
0237デフォルトの名無しさん
NGNGそーだね。つらいよね。
問答無用ってほんとにそのとおりだね。
0238デフォルトの名無しさん
NGNGgccのチェック機能は便利だよね。何度か助けられた。
0239デフォルトの名無しさん
NGNG0240デフォルトの名無しさん
NGNG>エラーが起きたらデフォでエラーメッセージが表示
これは余計なお世話だと思うが。
0241デフォルトの名無しさん
NGNGメモリが極端に少ないとか実行速度が極端に遅いとか
言語自体が対応していないとか使えない場合じゃないかぎり
使わない理由は無いでしょ。
0242デフォルトの名無しさん
NGNGはぁ？ 逆だろ。
0243デフォルトの名無しさん
NGNGこわーw
0244デフォルトの名無しさん
NGNG何もしない状態で、エラーが起きたとき、
エラー処理してない場合処理は続行される。
標準で何も表示されない。
エラー情報自分で表示するように造らなければならない。
のと
エラー処理してない場合も処理は中断される。
標準でちゃんと詳しいエラー情報が表示される。
エラー情報が必要ないときは簡単に消せる
のと
どちらが簡単で安全か一度考えて見れ。
0245デフォルトの名無しさん
NGNG0246デフォルトの名無しさん
NGNG0247デフォルトの名無しさん
NGNGOSのAPIとはWin32のことですか？
あれは似たような機能はあるが例外に対応していない。
C言語から呼び出すことをメインに考えているからね。
WinFXなら全て例外を返す。
0248デフォルトの名無しさん
NGNGWindows を意識してたのでへんな表現になっちゃったけど、許して。
現状ではそういうことなんだね〜。
0249デフォルトの名無しさん
NGNGだからWin32はやりにくいんだよ。
今は例外に対応している言語での開発が主流だからね。
わざわざ例外に変換しなくてはならない。
VCLにはWin32CheckといってAPIの戻り値のエラーを
例外に変換する関数が用意されているほど。
早くWinFXに移行しないかな。
0250デフォルトの名無しさん
NGNGつーか、WinFXって.NETじゃん。
ランタイムとかクラスライブラリまでOSのAPIって呼ぶのか？
基本サブシステムのシステムコールまでだろう、普通は
0251デフォルトの名無しさん
NGNG0252デフォルトの名無しさん
NGNG0253デフォルトの名無しさん
NGNG0254デフォルトの名無しさん
NGNGAPIは手続き型じゃないといけないとか、
中間コードではいけないとかいった
固定観念は捨てたほうが良い。
OSが提供している機能＝API
0255デフォルトの名無しさん
NGNGここの奴らは所詮一言語の規格の話をしているだけで、根本的なことは何も解っちゃいない。
はっきり言って笑っちゃうね。ｗ
0256デフォルトの名無しさん
NGNGCPUが出す例外とプログラミング言語言語の例外は違うから。
で、ここはカーネルスレじゃないから。
0257デフォルトの名無しさん
NGNG相手にするだけ不毛
0258デフォルトの名無しさん
NGNG残っている機能=APIじゃないの？
0259デフォルトの名無しさん
NGNGなんだよ？ OSがOSである最低限の不可分って？
APIがなんの略か知っているか？
http://yougo.ascii24.com/gh/04/000481.html
アプリケーションプログラムインターフェイスだぞ。
OSである最低限なんて言ったらアプリケーションはいらないわけで、
アプリケーションとのインターフェースも必要ないわけで。
今ある全てのAPIと呼ばれているもの全てがOSである最低限には含まれなくなるぞ。
0260デフォルトの名無しさん
NGNG0261デフォルトの名無しさん
NGNGここのアホってぬるぽ例外とかプログラミング言語の例外が投げていると思っているんだ。
あーおどろいた。
その調子でアホな議論を続けてくれたまへ。
0262デフォルトの名無しさん
NGNG例外の多くはライブラリが投げるもんだぞ。
CPUが直接の例外の発生元であることは少ない。
Javaのぬるぽなんかは実装にもよるだろうがCPUのアドレス0にアクセスすることもない。
もしアドレス0にアクセスしてメモリ保護がないCPUだと困るでしょ。
0263デフォルトの名無しさん
NGNG0264デフォルトの名無しさん
NGNGまったく笑わせてくれるねぇ。
おまいの思考はすでにライブラリで終わっている。
そのライブラリが何を行っているか全く考えていない。
さらに言えばOS上でのJVMの仕事すら解っていない。
つまり、すぱーくらすにおんぶにだっこな訳だ。
そりゃ箱庭環境だもんな。
カーネルモード、ユーザーモード、システムコール、特権モード
これらをぐーぐるで検索してから出直してこい。
0265デフォルトの名無しさん
NGNG調べた結果。やっぱりぬるぽにはCPUの例外は発生してないことが分かりました。
これで満足ですか？ それともCPUの例外が発生しているという証拠がありますか？
0266デフォルトの名無しさん
NGNGすぱーくらすが直接メモリ資源の確保でもしているとでも思っているのだろうか。
Javaまんせー
0267デフォルトの名無しさん
NGNG0268デフォルトの名無しさん
NGNGなんでこうプログラムの例外の発生元は全てCPUの例外だと
思っちゃう奴がいるんだろうね。そんなもの少ないのに。
0269デフォルトの名無しさん
NGNG0270デフォルトの名無しさん
NGNGライブラリがメモリ確保するために何を参照しているか。
OSのシステムコールは何を持って発せられるか。
OSがメモリ確保の失敗をとらえるために何を参照しているか。
OSのメモリ保護機構はCPUのどのような機能を使用しているのか。
OS,アプリはどんなCPUモードで動いているか。
ここまで教えてやって考えられないやつはアホだ。
0271デフォルトの名無しさん
NGNGそのジョークの意味さえわからないだろうよ。ｗ
0272デフォルトの名無しさん
NGNGあらゆる環境を考慮した模範的な解答は存在しない
0273デフォルトの名無しさん
NGNGおう、思ってる。
Java厨だから RuntimeException も基本的にVM辺りが投げなおしてると思ってるよ。
Javaじゃなくても例外ハンドラ取得できるタイプの例外って、大概そうなんじゃないの?
0274デフォルトの名無しさん
NGNGファイルオープンエラーの例外を本当にCPUが発生させていると思っているのか？
データベース接続エラーの例外を本当にCPUが発生させていると思っているのか？
ほとんどの例外はCPUの例外処理機構なんか利用してないよ。
0275デフォルトの名無しさん
NGNGhttp://support.microsoft.com/default.aspx?scid=kb;ja;406272
後はpage fault とか通常OSがキャッチするやつくらい?
0276デフォルトの名無しさん
NGNG2000では発生するがNT4では発生しないぞ。
つーか、Ｃしか知らない奴は例外といったら
ＣＰＵ例外しか頭に浮かばないから、話にならない。
0277デフォルトの名無しさん
NGNGって、話がずれてきてないか？
0278デフォルトの名無しさん
NGNG0279デフォルトの名無しさん
NGNGいちいち関数の戻り値とかチェックしてるときりがない。
おまえらはどうよ。
0280デフォルトの名無しさん
NGNG0281デフォルトの名無しさん
NGNGでも、エラーチェックを端折るとデバッグが激しくめんどくさい。
0282デフォルトの名無しさん
NGNG「エラー処理は正常ルートの処理の数倍面倒。」
これに気付いて以来、気が楽になりました。
0283デフォルトの名無しさん
NGNG極力統一しておいて、マクロ使って簡単にかけるようにしとく。
DirectShowのサンプルで見たのが最初だったかな。
//func1()を実行してでエラーが起きたらエラーコードCODE1のエラー処理
ERROR_CHECK(func1(),CODE1);
0284デフォルトの名無しさん
NGNGそのサンプル、どこでみれる？
0285283
NGNG昔のDirectX Media SDKに付いてた。
今なら多分、DirectX 9.0 SDKに付いてるんじゃないかな。
MSのサイトからダウンロードできるっしょ
0286デフォルトの名無しさん
NGNG関数の側で入力の型とか値を調べてる。
これは cerr<<"..." して exit(1) を関数にしておいて失敗時に呼ぶ。
何度も呼ぶ関数じゃないか、または本番で起こりうる状況のどちらかなのでアサートにはしてない。
(まあ、何度も呼ぶ関数の分岐も方向決まってればたいしたコストじゃないか)
あと、あまりありがたくない出力制限を行ったときはエラー出力に吐いてる。
この辺、ログファイルとかに吐くための関数自分で作ればよかったかなって思ってる。
0287デフォルトの名無しさん
NGNG終了。
0288デフォルトの名無しさん
NGNG0289デフォルトの名無しさん
NGNG例外捕捉禁止な環境で開発してるもんで。
0290デフォルトの名無しさん
NGNGそれを世間が間に受けたからこんな風になっちまったのか…
0291デフォルトの名無しさん
NGNGその内 "try {" や "} catch() {" が 11 行…。
イヤン。
0292デフォルトの名無しさん
NGNG0293291
NGNG漏れも市にたいです。
ゴチャゴチャしすぎ。書き直し決定。
ソケット/ストリーム関連だと、開放時にすら例外起こすからな…とか何とか考え(?)て、
機械的に try, catch を埋め込んでいったら、見事に 4 重ですよ。orz
ServerSocket -> Socket -> Stream -> 内部処理
皆さんは↑こんな場合はどうします?
0294r ◆r/etvCKR2A
NGNG全部同じレベルのcatchで受け取ったら？どうせもう何をする事も出来まい
try {
socket = serversock.accept()
InputStream is = socket.getInputStream();
whiel( is.ready() ) {
//:
}
}catch( IOException ) {
// :
}
つか、そのコードみせれ。
http://pc5.2ch.net/test/read.cgi/tech/1081863662/l50
ここに貼る。
0295デフォルトの名無しさん
NGNG0296291 のコード (1/3)
NGNGではまぁ、晒しageます。
といっても、当時のコード消しちゃったので、記憶を辿りつつ…ですが。
public void tryTryTryWithSocket() {
try { // for ServerSocket
ServerSocket serverSocket = new ServerSocket(port);
while (valid()) {
Socket socket = null;
try { // for Socket
Something somethingToBeDone = null;
ObjectInputStream in = null;
socket = serverSocket.accept();
/*
0297291 のコード (2/3)
NGNG容量の関係上、タブを2に変えます。
*/
// input part
try { // for InputStream
in = new ObjectInputStream(socket.getInputStream());
try {
somethingToBeDone = (Something)in.readObject();
}
catch (ClassNotFoundException e) {
// for InputStream
}
finally {
if (in != null)
in.close();
}
}
catch (IOException e) {
// for InputStream
}
/*
0298291 のコード (3/3)
NGNG*/
// process part
Something result = doWithSomething(somethingToBeDone);
// output part
ObjectOutputStream out = null;
try {
out = new ObjectOutputStream(socket.getOutputStream());
out.writeObject(result);
out.flush();
}
catch (IOException e) {
// for OutputStream
}
finally {
if (out != null)
out.close();
}
}
catch (IOException e) {
// for Socket
}
finally {
if (socket != null)
socket.close();
}
}
serverSocket.close();
}
/*
0299291 のコード (4/3 orz)
NGNG*/
catch (IOException e) {
// for ServerSocket
}
}
/*
こいつはテストコードだったこともあって、
結局は >>294 さんみたいな形になりました。
でも、どう改良できるか興味があります。
*/
0300291
NGNGつらつらとみっともないコードです。お目汚しスマソ。
0301r ◆r/etvCKR2A
NGNGServerSocket serverSocket = new ServerSocket(port);
try {
while( valid() )
acceptAndProcessByServerSocket( serverSocket );
} catch( IOException e ) {
// for ServerSocket
} finally {
serverSocket.close();
}
}
private void acceptAndProcessByServerSocket( ServerSocket serverSocket ) {
Socket socket = null;
try { // for Socket
socket = serverSocket.accept();
outputToSocket( socket, doWithSomething( inputFromSocket( socket ) ) );
} catch( IOException e ) {
// for Socket
} finally {
if( socket != null )
socket.close();
}
}
0302r ◆r/etvCKR2A
NGNGObjecetInputStream in = null;
try {
in = new ObjectInputStream( socket.getInputStream() );
return (Something)in.readObject();
} catch( IOException e ) {
// for InputStream
} catch( ClassNotFoundException e ) {
// for InputStream
} finally {
if( in != null )
in.close();
}
}
private void outputToSocket( Socket socket, Something something ) {
ObjectOutputStream out = null;
try {
out = new ObjectOutputStream(socket.getOutputStream());
out.writeObject(result);
out.flush();
} catch( IOException e ) {
// for OutputStream
} finally {
if( out != null )
out.close();
}
}
0303r ◆r/etvCKR2A
NGNG正直、IOExceptionだかなんだかが起きた後、
それ以降の処理が正常に行えるのか、たとえば、
InputStreamを開くのに失敗した後、
そこから取得するはずだったオブジェクトを
OutputStreamに書き出す処理に意味があるのかどうかは疑問だったが、
とりあえずオリジナルの動作に合わせててみた。
本質的にはtry-catchのネストの深さは変わっていないが、
とりあえず見た目のtry-catchだけ減らした。
0304デフォルトの名無しさん
NGNGおー、綺麗になってますね。
オリジナルの見た目の悪さと
変更のしにくさが解消されていると思いました。
> InputStreamを開くのに失敗した後、
> そこから取得するはずだったオブジェクトを
> OutputStreamに書き出す処理に意味があるのかどうかは疑問だったが、
ですね。
かなりやっつけで作っていましたから。恥しい…。
> 本質的にはtry-catchのネストの深さは変わっていないが、
> とりあえず見た目のtry-catchだけ減らした。
ここらへんは減らしにくいのでしょうね。
GJ です。
0305デフォルトの名無しさん
NGNGC/C++ では例外ではなくてエラーコードを返すほうが正しいと思う。
理由は、
(1) エラーコードにせよ例外にせよ、きちんとしたプログラムを書くときは
すべての可能性に対して対処するコードを書かないといけない。
例外だからエラー処理を省略できるわけでもない。
(2) １つの関数内で発生する可能性のあるエラーは、
その関数内でエラー処理を行うべきであって、
むやみに呼び出し元の catch をあてにすべきではない。
そうしないと関数定義の実装隠蔽の原則がくずれる。
(3) 例外はパフォーマンス上の欠点をもっている。
(4) 例外が使えないコンパイラやプラットフォームもあるので、
移植性を考えると使わないほうがよい。
例外はエラーコードの進化形じゃなくって、
setjmp/longjmp の進化形だと思うんだが。
0306デフォルトの名無しさん
NGNG例外の利点をまったくわかってない奴のセリフだな。
0307デフォルトの名無しさん
NGNG0308デフォルトの名無しさん
NGNG> (1) エラーコードにせよ例外にせよ、きちんとしたプログラムを書くときは
> すべての可能性に対して対処するコードを書かないといけない。
ミスで対処するコードを書かなかった場合でも止まる。
つまりフォールセーフな設計なのが例外の利点なのだが。
> (2) １つの関数内で発生する可能性のあるエラーは、
> その関数内でエラー処理を行うべきであって、
> むやみに呼び出し元の catch をあてにすべきではない。
その関数内でエラー処理が行えるのならエラーコードすら返す必要ないだろ。
エラーをコンソールに表示するかメッセージボックスに表示するかなんてのは
汎用的な関数になるほど関数内でわからないんだよ。
(3) 例外はパフォーマンス上の欠点をもっている。
C使ってください。
(4) 例外が使えないコンパイラやプラットフォームもあるので、
Cと標準ライブラリだけ使ってください。
0309デフォルトの名無しさん
NGNG利点があるのなら「パフォーマンス上のトレードオフがある」と言うべき。
そんなもん当たり前のことなので欠点とかいちいち言うことじゃない。
0310デフォルトの名無しさん
NGNG日本語が使えないコンパイラや(ry
printfやmallocが使えないプラットフォームなんてのもあるので(ry
0311デフォルトの名無しさん
NGNG>>305
(1), (2)
伝搬すべきエラー(例外)もあるでしょうから、
全ての可能性について網羅してしまうことはないかと。
網羅してしまうと、呼び出し元へのエラーは戻り値を通してしか
通知することができなくなってしまうでしょう。
戻り値ありきな考え方の様に思えます。
(3), (4)
環境によりけり、ですね。
そういえば、C/C++ で例外使ったこと無いな。
> 例外はエラーコードの進化形じゃなくって、
> setjmp/longjmp の進化形だと思うんだが。
機能的にはそうなんでしょうね。
個人的には単純に、例外 = エラーコード + setjmp/longjmp
だと思ってます。
0312デフォルトの名無しさん
NGNG>> (1) エラーコードにせよ例外にせよ、きちんとしたプログラムを書くときは
>> すべての可能性に対して対処するコードを書かないといけない。
>ミスで対処するコードを書かなかった場合でも止まる。
>つまりフォールセーフな設計なのが例外の利点なのだが。
ミスでエラー処理を書かなかった場合で、
それで例外がスローされて親で ctach されたとしてもフェイルセーフとは言えない。
その後の正常動作が少しも保証されないからね。
>> (2) １つの関数内で発生する可能性のあるエラーは、
>> その関数内でエラー処理を行うべきであって、
>> むやみに呼び出し元の catch をあてにすべきではない。
>その関数内でエラー処理が行えるのならエラーコードすら返す必要ないだろ。
>エラーをコンソールに表示するかメッセージボックスに表示するかなんてのは
>汎用的な関数になるほど関数内でわからないんだよ。
ここでいう「エラー処理」というのは、
エラーが発生する可能性があることをプログラマが認識して、
エラーコードの変換や、その関数で使用しているリソースを解放した上で、
明示的に呼び出し側にエラーコードを返す、
という意味です。
>> (3) 例外はパフォーマンス上の欠点をもっている。
これはトレードオフということで了解です。
>>(4) 例外が使えないコンパイラやプラットフォームもあるので、
>Cと標準ライブラリだけ使ってください。
C++ の例外以外の機能を捨てるつもりはありません。
0313デフォルトの名無しさん
NGNG(1), (2)
> 伝搬すべきエラー(例外)もあるでしょうから、
> 全ての可能性について網羅してしまうことはないかと。
それはそうですが、コーディング規約の一貫として、
すべてのエラーコードの判定をコーディングするのがよいかと思います。
プログラマがすべてのエラーを認識している証となりますから。
↓こんなコードでも書くべき。
if (err == ERR_NO_MEMORY) {
return err;
}
> 網羅してしまうと、呼び出し元へのエラーは戻り値を通してしか
> 通知することができなくなってしまうでしょう。
> 戻り値ありきな考え方の様に思えます。
すいません、これで何が問題なのかよくわからないのですが。。
もう少しご説明願えますか？
0314デフォルトの名無しさん
NGNGああ、関数内でエラーに対処するコード(それこそメッセージ表示
とか)を書けというわけではなく、捕捉して再送しろ、ということ
でしたか。(from >>312 の (2) と >>313 の後半)
確かに、呼び出された方は自分がどんなエラーコード
(例外)を投げるのかをきちんと把握しておくべきですね。
> すいません、これで何が問題なのかよくわからないのですが。。
> もう少しご説明願えますか？
や、すみません。忘れてください。orz
お酒飲みながら書いてたので、今自分でもその考えを再構築できな
い…。
0315デフォルトの名無しさん
NGNG> ミスでエラー処理を書かなかった場合で、
> それで例外がスローされて親で ctach されたとしてもフェイルセーフとは言えない。
> その後の正常動作が少しも保証されないからね。
はぁ。例を出さなきゃわかりませんか。
ファイル移動する関数を作るとする。
処理の内容は以下のとおり。
１．ファイルコピー関数の呼び出し。
２．ファイル削除関数の呼び出し。
もしこの関数がミスでエラー処理をしていなかった場合、
エラーコードチェック型だと
１のファイルコピー関数の呼び出しが容量不足で失敗しても
２のファイル削除関数が呼び出されます。
しかし例外だとエラー処理をしていなくても２のファイル削除関数が
実行されることはありません。これがフェイルセーフということです。
フェイルセーフとは正常動作を保証することじゃありません。
失敗（フェール）しても安全（セーフ）であるということです。
用語自体もまったくわかっていませんね。
0316デフォルトの名無しさん
NGNG> それはそうですが、コーディング規約の一貫として、
> すべてのエラーコードの判定をコーディングするのがよいかと思います。
現実的に無理です。こんなことが可能ならミスなんてありえません。
0317デフォルトの名無しさん
NGNGBを0にして呼び出したとき（ゼロ除算）のエラーコードを考えれば
エラーコードを返す方式の欠点が良くわかる。
徹底するともう戻り値はエラーコードを返すことにしか使えなくなってしまう。
関数Xで関数Yを呼び出し、関数Yで関数Zを呼び出す。
最初はエラーが発生する仕様ではなかったが、
あとから関数Zがエラーを発生することができてしまった。
そうすると関数Xも関数Yも全部修正が入る。これもエラーコードの欠点。
さらに関数X、Y、Zがともに引数を返す仕様であればもっと最悪。
さらに関数Yが最初っからエラーコードを返す仕様の関数で、あとから関数Zが
エラーを返すに仕様になった場合、関数Yがどうやって関数Zのエラーコードを
返すかを考えるともう泥沼。
0318デフォルトの名無しさん
NGNG0319デフォルトの名無しさん
NGNG返答するのも疲れる内容だから、他の人に反論してもらいたい。
age
0320デフォルトの名無しさん
NGNGそれが許されるならエラーコードすら返す必要ないじゃんｗ
0321デフォルトの名無しさん
NGNGだから君は例外の利点をまったくわかってないと言われるんです。
常識的な内容だからこれぐらい知っておきなさい。
0322デフォルトの名無しさん
NGNG0323デフォルトの名無しさん
NGNG> 徹底するともう戻り値はエラーコードを返すことにしか使えなくなってしまう。
それはそれできれいな設計では？
0324デフォルトの名無しさん
NGNG> Bを0にして呼び出したとき（ゼロ除算）のエラーコードを考えれば
数値計算系の関数は、入力の数値が規定外であれば、
その挙動は不定ということで十分。
0325デフォルトの名無しさん
NGNG> エラーを返すに仕様になった場合、関数Yがどうやって関数Zのエラーコードを
> 返すかを考えるともう泥沼。
何もエラーコードを直接の戻り値にしなくてもいい。
Windows API のように GetLastError() を用意してもいいよ。
0326デフォルトの名無しさん
NGNGそんなのは場合によりけりだっつうの
厳密にチェックすべきシチュエーションだってあるだろ
0327デフォルトの名無しさん
NGNG0328デフォルトの名無しさん
NGNG>>324
だす
0329デフォルトの名無しさん
NGNGそうかなぁ。
数値計算って一般に高速性を要するでしょう？
いずれにしても例外を使ってオーバーヘッドを増やすほうがよくないと思うけどなぁ。
あんまり極論だとは思わないよ。
0330デフォルトの名無しさん
NGNG演算関数が例外を投げる事はパフォーマンスに影響を与えないだろうよ。
除算関数のdenominatorに0が与えられるなんてのはlogic_errorの領分であって
そんな事が頻繁に起こりうる（0が定常的に与えつづけられる）なら直前に条件分岐で弾くべきでないの？
0331デフォルトの名無しさん
NGNG0332デフォルトの名無しさん
NGNGアフォですか？
0333デフォルトの名無しさん
NGNGということであれば、規定外の入力に対しては動作不定であってもよいわけで、
例外はいらないでしょう？
0334デフォルトの名無しさん
NGNG見苦しいよ
0335デフォルトの名無しさん
NGNGすいません、まじめに話しをしているんですけど。
もしかして私が何か勘違いしているのかな。
0336デフォルトの名無しさん
NGNG弾き忘れたときにどうなるかが問題。
イレギュラーな解を元に処理を続行してしまうか、unexceptedでterminateされてしまうか。
潜在したバグほど厄介なものは無いだろう
0337デフォルトの名無しさん
NGNGもちろん、関数の実装側では除算の前にゼロチェックするぐらいの
堅牢さは必要だと思っていますよ。
問題は除算が必要なときに万が一ゼロであった場合にどうするかです。
その場合、
[A] 動作不定として処理する
[B] エラーコードを返す
[C] 例外を投げる
という３種類のうちのいずれを選択するか、というのが議題ですが、
[C] の優位性って特にありますか？
[A] はつまり、「呼び出し側で入力値の検査をしないさい」
という仕様であり、必ずしもエラーチェックを行わないわけではありません。
単にエラーチェックを呼び出し側が行うか、関数側が行うかの問題です。
[B] は関数側がやってくれます。
[C] も関数側がすべて明示的にやるのが望ましいですが、
>>336 さんのご意見では、関数の実装が完璧でなくても、
例外が投げられる (ことがある) ので、落ちることはないと言いたいわけですよね。
しかし、単に「落ちない」というのを利点にするのであれば
[A] も同じ性質を備えているわけですよ。
0338デフォルトの名無しさん
NGNG0339デフォルトの名無しさん
NGNGえ？そういう発想なんですか？
ちょっと考えてみます。
0340デフォルトの名無しさん
NGNG「捕捉されない例外が伝搬するのが良い」と言っている？
0341デフォルトの名無しさん
NGNG>その場でログはいてexitで無問題
これが例外の便利さを端的に語っていると思うのだが。catchしなかったらデフォルトこの動作でしょ
0342デフォルトの名無しさん
NGNGそう、それをわかってない奴が多いよな
0343デフォルトの名無しさん
NGNG利用側
事前引数チェック
エラーコードチェック
例外
関数側
個人的には０除算ぐらいで例外投げるのはやりすぎな気がする
正常でない動作に気を使うのは誰だ？上か？下か？みたいな感じで使い分ければいいんでないのかなぁ
せっかく例外で上手いこと書けるケースがあるんだし、そういう場面では使えばいい
だからといって何でもかんでも例外で済ませようとすると小回りが…
そんな気持ち
# あと勝手にエラー出力するような関数は、そのライブラリのポリシー次第だと思た
0344デフォルトの名無しさん
NGNG>個人的には０除算ぐらいで例外投げるのはやりすぎな気がする
アホか
第2引数に0を受け取った関数 int divide(int, int) はどう振舞ったらいいんだ？
0345デフォルトの名無しさん
NGNG除算をわざわざ関数にした程度なら、０を返しておけばいいんでない？
利用目的次第だとは思うけど
0346デフォルトの名無しさん
NGNG本気でわかってないんだな。
わかりやすいように除算演算子を関数に書き換えて見せたのに。
"result = 4 / 0" やら "result = divide(4, 0)"やらが
黙って0を返すのを見てなんとも思わない？
0347デフォルトの名無しさん
NGNGそれって結局その関数がどのように利用されるか次第なのではないの？
私は勝手に解釈して、そのような機能と決め打ってしまったけど
本当に例外を投げて欲しいケースで利用するならそのように作ればよろしいのでは？
0348デフォルトの名無しさん
NGNGまだわからないかな〜。除算演算子は0割されたときに何を返せばいいの？
0349デフォルトの名無しさん
NGNGpublic void tryTryTryWithSocket() throws IOException {
try {
Socket socket = serverSocket.accept();
try {
ObjectInputStream in = new ObjectInputStream(socket.getInputStream());
try {
Something somethingToBeDone = (Something)in.readObject();
Something result = doWithSomething(somethingToBeDone);
ObjectOutputStream out = new ObjectOutputStream(socket.getOutputStream());
try {
out.writeObject(result);
} finally {
out.close();
}
} finally {
in.close();
}
} finally {
socket.close();
}
} finally {
serverSocket.close();
}
}
４重ぐらいで怯むな。でもメソッド分けた方が良いな。
0350デフォルトの名無しさん
NGNG０除算したら例外をcatchするからそれを使え？
そりゃそうだわな
0351デフォルトの名無しさん
NGNG344では用途が限定されていないんだから、問題の関数のプロトタイプは
完全なものに仕様とすると、（たとえば）以下のようになる。
pair<bool, int> divide(int num, int div);
bool divide(int num, int div, int& result);
どうみても使いづらい関数だよな？
0352デフォルトの名無しさん
NGNGこのスレ的には、正しいエラー処理が強制される例外はあまりよろしくない存在だろう。
0353デフォルトの名無しさん
NGNG0354デフォルトの名無しさん
NGNG学者はアセンブラでもやってろ
0355マイク ◆yrBrqfF1Ew
NGNG0356デフォルトの名無しさん
NGNGtry-catchで、メソッドごとに、あらゆる例外に対して処理を行います。
おかげで短いはずの1メソッドが100行軽く超えます。
0357デフォルトの名無しさん
NGNGifで、メソッドごとに、あらゆるエラーコードに対して処理を行います。
おかげで短いはずの1メソッドが100行軽く超えます。
で、何が言いたいの？ >>356
0358デフォルトの名無しさん
NGNGエラーチェックしても行が伸びなくて済むな。
エラーを上位関数にそのまま返すのなら一行も増やす必要が無い。
それにたいしてエラーコードだと一行ごとにエラーチェックする場合、
チェック関数呼び出すために少なくとも一行は増やす必要がある。
foo(bar()) という書き方もできなくなるなしな。
0359デフォルトの名無しさん
NGNGそうやって最上位まで返すとabortします
0360デフォルトの名無しさん
NGNGエラーコードの場合でも同じだけど？
しかもエラーメッセージすら表示されずに終了するね。
0361デフォルトの名無しさん
NGNGそりゃエラーが出ているのに途中でエラー処理をしなかったら落ちて当然でしょう。
それともエラーが出ているのに進んでほしいの？
エラーコードの場合エラー処理をしなかったらエラーが出ても進みますね。最悪ですね。
0362デフォルトの名無しさん
NGNG0363デフォルトの名無しさん
NGNGif (! this.has発射許可()) {
throw new 発射許可がねーよException();
}
粛々と準備を進める();
}
int 核ミサイル発射準備() {
if (! this.has発射許可()) {
return 発射許可がねーよERROR_CODE;
}
粛々と準備を進める();
return 0;
}
us.核ミサイル発射準備();
us.発射();
0364デフォルトの名無しさん
NGNG核ミサイル発射システムがエラーコードチェック拾い忘れで
そのまま発射したらどうしようｗ
0365デフォルトの名無しさん
NGNGそんなもんはデバッグの段階でつぶしとくんだよ。
落ちてくれれば発見できたエラーも、握りつぶされて
一見正常に動いているように振舞ってしまうと発見が遅れる（または発見されない）
0366デフォルトの名無しさん
NGNGその後核ミサイル発射停止システムを動かせばいい
エラーチェックがエラーコードなら核ミサイル発射停止システムは
いきなり止まったりしないしな。
0367デフォルトの名無しさん
NGNG停止システムと発射システムが同一のインスタンスに共存するのか。かなり怖いな。
0368デフォルトの名無しさん
NGNGたんに異常状態で動作（暴走）しているだけ。暴走しているかどうか
わかるまでには時間がかかるため、これは止まるよりもさらに太刀が悪い。
核ミサイル発射停止システム実行。
・
・
・
数分後
「おい？ まだ動いているんじゃないのか？」
「でも停止しましたって表示されているぞ。」
「本当に止まっているのか？」
「表示は停止しましたとでていますが肝心のシステムが正常に作動していません。」
「なんでエラー表示されなかったんだ？」
「予備の核ミサイル発射停止システムを実行しろ！」
「間に合いません！」
0369デフォルトの名無しさん
NGNG0370デフォルトの名無しさん
NGNG{
stop();
print("停止しました。");
return 0;
}
stop()のエラーチェックをし忘れるとエラーコードだと>>368のようになります。
例外のほうがより安全ですね。
0371デフォルトの名無しさん
NGNG0372デフォルトの名無しさん
NGNG暴走してもSTOPキーで止められるから。
0373デフォルトの名無しさん
NGNG0374デフォルトの名無しさん
NGNG0375デフォルトの名無しさん
NGNG03761
NGNG0377デフォルトの名無しさん
NGNG0378デフォルトの名無しさん
NGNGというプロジェクトに配属されたんですが、こんな例外の使い方ってアリなんでしょうか？
0379デフォルトの名無しさん
NGNGCOM?
0380デフォルトの名無しさん
NGNGさら仕上げ
0381デフォルトの名無しさん
NGNGスルーされまくってるし
0382デフォルトの名無しさん
NGNG0383デフォルトの名無しさん
NGNGjmp_buf* __c_errjmp;
c_throw(code) {
__c_throw_code = code;
longjmp(__c_errjmp,1);
}
#define c_try_begin \
{ jmp_buf* __c_errjmp_save = __c_errjmp, \
__c_errjmp_tmp = alloca(sizeof(jmp_buf)); \
__c_errjmp = __c_errjmp_tmp; \
if (!setjmp(__c_errjmp)) {
#define c_try_end \
__c_errjmp = __c_errjmp_save;
#define c_catch_begin \
} else { \
__c_errjmp = __c_errjmp_save;
#define c_catch_end \
} \
}
0384デフォルトの名無しさん
NGNGtest2(x) { if (x == 2) c_throw(2);}
test3(x) { if (x == 3) c_throw(3);}
test4(x) {
if (x == 4) c_throw(4);
c_try_begin
test1(x-1), test2(x-1), test3(x-1);
c_try_end
return 1; // true
c_catch_begin
printf("catch '%s' err :%d\n", __FUNCTION__, __c_throw_code);
c_throw(__c_throw_code);
return 2; // catch true
c_catch_end
return 3; // true
}
test(x) {
c_try_begin
test1(x), test2(x), test3(x);
printf("true => %d\n",test4(x));
c_try_end
c_catch_begin
printf("catch '%s' err :%d\n", __FUNCTION__, __c_throw_code);
c_catch_end
}
こういうことしてる人いますか？
実際使う場合はWindowsの__tryとかも考慮しなきゃいけないけど。
いまいちですよね・・・。
0385デフォルトの名無しさん
NGNG実際tryハンドラ書くとこはそんなにないから、そこは我慢して書く。
Cでこういうことする場合はヒープの扱いが面倒だけど。
0386デフォルトの名無しさん
NGNG0388デフォルトの名無しさん
NGNGミサイルはきちんと運用できなきゃ飛ばないので安心といえば安心。
0389デフォルトの名無しさん
NGNG自分はそういうことCでやる場合はヒープマネージャを作って
適当なハンドラのブロックで一気に開放させてる
0390デフォルトの名無しさん
NGNG/ 気 !
l |
''''''''''‐-､, | に ｜
::::::::::::::::::::＼ | |
:::::::::::::::::::::::::ヽ _,,,,,,_ .| す |
:::::::::::::::::::::::::::::':, ,.-''"::::::::::::｀l |
::::::::::::::::::::;ﾍ::::;::i ／::::::::::::::::::::::::| る l
::::::::::::::::::::'､|ヽ!ヾ /::::::::A:::;::::/!::ﾑli |
:::::::::::::::::::､:'､ ,':::::::::ハ;ハ;l ﾚ' '|ヽ な /
:::::::::::::::;:::| `! ,.,.._ ﾚi::;lV. ┃ ┃''"ﾑ ／
::::::/l:::ハ:|,/ i ヽﾍ, '〈| ソ'''''､
:::/ ,|/,,／ ', l, ヽ. l､ r一‐:､ /:::::::::::'､
/ | '' ＼ 丶.ll''r､.,_ /::`':.､ ヽ--‐',.イ､::::::::::::::'､
:‐┴:､. `i''y'l |: : : ｀`''ヽ‐''ヾil´`i';､''" / >､:i､::::::',
＼ '-'､/ : : : : : : :`: : : lL,, l /_ ,//: :＼'､;::､
0391デフォルトの名無しさん
NGNG鼻から悪魔が出る
■ このスレッドは過去ログ倉庫に格納されています