いちいち例外クラスを定義するのがめんどくさい
いちいち返値を定義するのがめんどくさい
戻り値は簡単だよ。とりあえず-1かNULL返しとけば良いんだし。
5 ：
仕様書無しさん ：2011/01/27(木) 13:23:53
http://www.parashift.com/c++-faq/exceptions.html * [17.1] What are some ways try / catch / throw can improve software quality?
* [17.2] I'm still not convinced: a 4-line code snippet shows that return-codes aren't any worse than exceptions; why should I therefore use exceptions on an application that is orders of magnitude larger?
* [17.3] How do exceptions simplify my function return type and parameter types?
* [17.4] What does it mean that exceptions separate the "good path" (or "happy path") from the "bad path"?
* [17.5] Okay, so you're saying exception handling is easy and simple, right? New!
* [17.6] Exception handling seems to make my life more difficult; clearly I'm not the problem, am I??
* [17.7] I have too many try blocks; what can I do about it?
...
>>5 訳してみた。
http://www.parashift.com/c++-faq/exceptions.html * [17.1] try/catch/throw がどうソフトウェアの品質を向上させるの？
* [17.2] わからないな。４行ほどのコード片でも戻り値が例外よりちっとも悪くないことを示すことができる。それなのになんでもっと規模の大きなアプリケーションで例外を使わなくちゃいけないの？
* [17.3] 例外がどう戻り値の型や引数の型を単純にするの？
* [17.4] 例外が「正常系」と「異常系」とを分けるというのはどういう意味？
* [17.5] はいはい、じゃぁあんたは例外処理は簡単で単純だと言うんだね？合ってる？
* [17.6] 例外処理は俺の人生をより面倒にするようだ。俺は悪くない、よね？
* [17.7] try ブロック多すぎ。どうにかできないの？
...
まさに FAQ
FAQって、いつもふぁっくゆーって読んでる。
例外が正しく使える、と言うのを定義した場合、それはどの様になる？
例外安全は必要条件だな
少し読まない間に１スレも進みやがって・・・
例外 VS 戻り値っていつも理解できるものと
try {
忘れた
>>14 エラーを戻り値で返す場合の戻り値の検査を省略するのと同じで
コーディングの方法としては悪いから警告されているだけ。
lintみたいなやつで、言語がだしている警告ではないので
意図してやってるなら問題ないよ。
普通のコーディングでは、Exceptionという汎用的な例外をトラップしたら、
例外を再スローするわけで、再スローするならば警告は出ない。
もし、Exceptionをトラップして、再スローしない場合があるとすれば、
どんなエラーが起きても（バグがあったとしてもという意味）
落ちないプログラムを作るときだけ。それも書くところは一箇所になるだろう。
説明はこれでいいかな？
Exceptionのような汎用の例外をトラップすることが
18 ：
12 ：2011/01/28(金) 01:43:10
>>12 のあとで、なんか話が続いたって話はないみたいだし
今も反論もないし、この件は例外派が言い負かしたってことでよかったのか。
>>12 > 話を戻すと、MyException以外の例外がfoo()から発生したら
> 仕様書に書いてないバグだから考えなくていいんじゃね？
いや、そもそもバクではない。
>>19 なんで？
たとえばヌルポがでたらバグでしょ。
ぬるぽしか思いつかないのか。
>>19 話がズレてる。
バグだといったのは、戻り値派の連中で、
仕様外の値が帰ってきたら
バグだといったんだ。
だから、俺にそれをバグじゃないと言われても困る。
いうなら、「関数から仕様外の値が返ってきても
バグじゃない」と、戻り値派の連中に言ってくれ。
関数から仕様に記述されていない値を返すのは明らかにその関数のバグだが、
> 関数から仕様に記述されていない例外が発生するのはバグとは言えない。
>>24 そもそも例外とはそのようなものだから。
逆に、決まった例外しか通知されないような状況を考えてみるといい。
「この関数はファイルIO例外しか投げません」と決めていても、
処理途中で別の例外的事象が発生したらどうすればいいんだ？
> 処理途中で別の例外的事象が発生したらどうすればいいんだ？
あと、参考までに
・発生しうる例外を列挙するために多大な労力をかけるか(それでも網羅しきれない)
>>28 戻り値の場合だと、それらはどうやって解決するんだ？
例外よりも簡単な方法があるのか？
その方法を書いてくれると、
俺は、それと同等の量で例外を使ったコードを書ける自信があるよ。
> 例外と付き合うにはどれかを選ぶしか無いと思うよ。
try {
foo()
} catch(Exception e) {
throw new FooException(e)
}
これでいいんじゃね？
>>29 戻り値だと、基本二番目の方法だね。それぞれの関数が上に伝える値を明示的に制御する。
一番目と三番目は戻り値では起きない問題。
>>25 Javaの場合に考えられるのはぬるぽ、OutOfMemory, 0除算、スタックオーバーフロー、無効な配列インデックスなど。
でもほとんどの場合コーディングミスによって発生するものなので、テスト段階で取り除けとしか言いようがないな。
例外が存在しないC言語なんかの場合、例外的事象が発生すればセグメンテーションフォルトや0除算を引き起こす。
そうなれば言語の仕組みとは別の所で強制終了となる。
戻り値だろうと例外だろうと「例外的事象」とか「想定外の例外」からは逃れられない。
だからがんばってデバッグしろとしか言いようがないな。
>>30 > 一番目と三番目は戻り値では起きない問題。
問題とか何言ってるの？
戻り値だと、2番目の方法を使うんでしょ？
例外でも２番目の方法を使えば、問題は解決だよね？
2番目を使えば問題は解決なんだから、
１番目と3番目では問題があるなんて、
をわざわざ言う必要ないじゃないか
ということで、このスレとしては例外は関数一つ一つにtry-catchの網をかぶせる方向で。
>>31 > 例外が存在しないC言語なんかの場合、例外的事象が発生すればセグメンテーションフォルトや0除算を引き起こす。
> そうなれば言語の仕組みとは別の所で強制終了となる。
それまずくない？
もしリソース解放する必要があったら戻り値の場合どうするの
この場合のリソースってのは、たとえば一時ファイルを作成して
処理終了後に一時ファイルを削除する。なんてフローがあったとき。
例外が存在しないC言語だと、強制終了になるというのなら、
リソースの解放ができないってことだよね。
>>34 だからLockファイルが消されずに残ってるなんてことがよくある
JavaにしたってVM落ちたとかマシンが落ちたとかの事態を想定して、
>>33 > ということで、このスレとしては例外は関数一つ一つにtry-catchの網をかぶせる方向で。
その方向に反論するわけじゃなくて、
関数一つ一つにtry-catchの網をかぶせて、
catchした後どういう処理をするの？
この答えは戻り値の場合もどうせ同じことだから、
戻り値の場合で答えてくれていいんだけど
要するに、
int main() {
if(func1() == ERROR) {
ここに何を書くの？
}
if(func2() == ERROR) {
ここに何を書くの？
}
if(func3() == ERROR) {
ここに何を書くの？
}
}
>>28 >>30 一番目は問題外で、誰もそんな選択肢は取らない。
二番目はよく見る状況だけど、あまり多すぎるようだと例外をうまく使えてない可能性が高い。
三番目はわりとよく見る選択肢で、問題だとは思わない。
int main() {
int main() {
if(func1() == ERROR) {
>>41 終了させるなら、ログか標準出力にどこでどういったエラーが発生したかを吐き出して終了
が普通のセンスじゃね？
エラー処理を正しく作れないプログラマ多いね。
例外とか関係なく、エラー処理のやり方おかしい奴おおすぎ。
>>45 > 例外の問題はこのような状況で落ちてしまうからだ。
catch書けば落ちないだろ
馬鹿なのか？
聞くまでもなく馬鹿そのものだろう
バグとかよくわからん例外用のコードが必要なのが例外の欠点。
javaは可能性のある例外すべて対処してないとエラーでるな
>>47 まさにスレタイ通りの人発見
もしかしてcatch(Exception)やっちゃう人？
どんな種類の例外が来るか分からないのに？
>>45 てーか普通戻り値ってたとえば1だったり2だったり384だったりするけど
エラーのときだけ-1が帰ってくるようなもんじゃないのか。
だったら
ret=func();
if(ret < 0) {
異常処理；
return ret; //または return -1;
}
retを使った正常処理；
とすればインデントが深くならず異常が目立つ。
if(ret <0) ってcatch(Exception)とやってることが全く同じじゃんｗ
>>53 同じじゃないよ
戻り値-1は呼び出した関数が失敗。復帰は容易
catch(Exception)はどこかで誰かが原因不明の失敗。復帰させる自信がなければログはいてアプリ終了
>catch(Exception)はどこかで誰かが原因不明の失敗。
>49
ハゲではなくフサフサであった場合。
本当はハゲだけど見栄を張りたい場合、
＞本当はハゲだけど見栄を張りたい場合、
俺のわかる話に戻してもらおうか
C++ではcatch(...)で全ての例外を拾えることを
>>55 戻り値は勝手に伝播しないので、火元の分からないエラーは存在しない（はず）
if (ret == -1) longjmp(...) とかやってない限りはｗ
例外はこれが簡単に起こるのが弱点
catch(...)で防げるかも知れないが、もはや正常系には戻れない
>>62 もう少し訓練を積んだほうがいいんじゃないか？
伝搬とか考えるからだめなんだよ。
foo()という関数があった、
その中の実装はお前が考えることではない。
foo()という関数がSQLExceptionという例外を出した、
それはもしかしたら中で使っている何かがだしたのかもしれないが
内部の実装なんだからお前が考えることではない。
凄くシンプルに、foo()がSQLExceptionをだしたと考えれば、
なんの問題もないはずだ。違うかね？
>>62 > catch(...)で防げるかも知れないが、もはや正常系には戻れない
catch(...)で防げると分かっていて、正常系に戻れないとする
根拠はなんだ？
戻り値にはない理由で答えよ。
こんな話を聞いたことがある。
try{
try{
例外だすとは思わなかったのに、
>>66 ではないが。
何の例外かなどどうでもいい、hage()をコールした事実だけがあればいい。
と言う処理もある。
例外が出たってことは、
>>70 > 何の例外かなどどうでもいい、hage()をコールした事実だけがあればいい。
じゃあ、コールした事実があればいいということを
明確にするべきだよ。
つまり、try catchで囲って、catchにコメントでなにもしない理由を書く。
戻り値のエラーが省略されているのをみたら、
普通の人はエラーチェックをサボってる
このままだとエラーが起きているのに正常終了してしまう。
これはバグだって思う。
>>71 関数作った奴の思想がなんでもかんでも例外にしていたら
そんなことできねぇんだよ
>>73 アホか、コールされる関数の仕様に、XXXで使用する場合、エラー処理不要。
と書けばいい
戻り値チェックの一番の欠点は、
>>75 > アホか、コールされる関数の仕様に、XXXで使用する場合、エラー処理不要。
> と書けばいい
なんで関数側で利用方法を決めるんだよｗ
逆だろ。
お前設計できないな。
>>76 わざわざ駄目な例を出して批判しても、説得力がない。
>>76 そういうのだったらエラーチェックするじゃん
どーでもいい関数が例外吐いて処理止めちまうとか嫌じゃん
開発やってるときなんていちいちドキュメント書かないから
そいつのところいってあれこれ話すの面倒臭いよ
try{
>>78 えーｗ わざわざダメな例を出したのは
エラー出ても無視していいんだよ！なんていってる方じゃないかｗ
>>77 菅-笑える反論なんだが。
利用方法を指定しない関数なんて有るのか?
>>81 > 結局、使っている関数の中身をみる必要がある。
> そうしないと落ちてしまうからだ。
おれは、hageの中身を見てないんだが、
このコードは落ちないだろ？ｗ
>>79 ファイルを開く処理でファイルがないときに例外を吐くとかウザイぜ
>>82 キミは議論に参加しない方がいいよ、混ぜっ返すだけだから
>>84 中身みてないなら、なんでhageだけ囲んでいるんだよｗ
>>81 いまその話してなくね？
それって対処済みなわけじゃん
１回引っかからないとそいつが例外吐くかどうかわからないよね
>>83 お前の言ってる利用方法ってなんのことだ？
なんかすごい勘違いをしてそうだな。
> アホか、コールされる関数の仕様に、XXXで使用する場合、エラー処理不要
このXXXには具体的に何が入るんだ？
いってみ。
エラーを返すのに、絶対にエラー処理が不要なんて
関数はありえないだろ。
>>85 > ファイルを開く処理でファイルがないときに例外を吐くとかウザイぜ
例外を出さないと、
ファイルを開いてないのに、
開いてないファイルに書き込もうとするよな？
>＞87
try{
>>92 わざわざ特殊な例を出しても、説得力がない。
>>92 > fileopen1(&path);←読めなかったらfileopen2で読むからスルーでいいんだよ例外吐くな馬鹿！
そういうことは、コメントで書かずに、
読めなかったらスルーするという
コードを書いてください。
>>93 えー、しょっちゅうやるよー
iniになければ～
DB1になければ～
C:\になければ～
regになければ～
少なくとも俺の経験ではめっちゃある
関数用意した奴が例外だと思ってるもんでも
呼び出した側からしたら例外になんてならないと思ってるとかいう認識の違いから
こういうのよくおきるよね
現に
>>90 なんてこういうコードだって可能性がすっぽり頭から抜けてるもんね
まあ、例外あってもいいんだけど
>>95 別にそれは例外でもかけるから、ネタとして取り上げる価値がない。
void foo() って関数の中で使っている関数が
100 ：
99 ：2011/01/28(金) 22:46:34
たとえば0除算エラーが起きたら
>>99 そりゃ戻り値必要なんだろその関数ｗ
>>100 ０徐は明示的なチェック（仕様的な）が必要
例外で片付けては駄目
>>100 関数内で落ちるんだから、どうでもいいじゃん。
作った奴の責任だ。
例外は他人に責任を押し付けるから厄介。
>>99 > そりゃ戻り値必要なんだろその関数ｗ
いや、戻り値は要らない。
>
>>100 > ０徐は明示的なチェック（仕様的な）が必要
> 例外で片付けては駄目
それでもやってしまった場合はどうするんだ？
>>102 > 例外は他人に責任を押し付けるから厄介。
戻り値を返すってことは、他人に責任を押し付けてることになるだろ？
>>104 ならないよ。使う側はソース変えるつもり無いし。
必死で戻り値に色々な意味を与えても使う側はスルー。
大体、ｃの標準関数だって、ほとどのプログラマは戻り値無視。
何か特別な事情ある時だけチェックし、エラー処理する。
戻り値を返さない関数が、
> 大体、ｃの標準関数だって、ほとどのプログラマは戻り値無視。
>>106 そんなぐだぐだな環境でPGやってるのか。
>>108 戻り値使ってる所ではよくある光景だったね。
前の会社でデスマになってた。
エラーチェックしてないものだから
動いてるのになんかおかしい！っていつも騒いでたよｗ
今は例外を使っているから
このような問題はなくなったね。
そもそもよっぽど簡単なプログラムじゃない限り、関数の戻り値によって制御パス変える
> 今は例外を使っているから
>>103 はぁ？ってかお前、明らかに議論に加われるレベルじゃねーぞ
>>106 何が言いたいのか意味不明
よく読んでないけど
発生させてなかった正常系例外が途中で加わったときぐらい混乱する内容なの？
>>110 例外ってのは0除算と同じで通常の制御パスとは
すでに外れたルートに突入してるんだよ。
0除算やったら落ちるだろ？
それと同じ。
むしろ通常の制御パスから
以上ルートを取り除くことに成功したわけで、
通常の制御パスがよりシンプルになる。
>>115 どう考えても０徐の対処は仕様的な決定が必要になる
出した例に意味がない
お前、さっきから背伸びして参加してる異常にレベルが低い奴？
>>114 voidがboolになるだけなら簡単だけど、
元々の関数がintの場合、たかがエラーのために、
intがlongになってintの範囲は戻り値のために使うから、
それ以外の範囲の値をエラーにしなくちゃならないからね。
エラーと言っても、なんのエラーなのかを返さないといけないから
単純にfalseを返せばすむって話じゃない。
関数の戻り値の型ごとに複雑な仕組みで
エラーの値を返さなければならなくなる。
>>116 > どう考えても０徐の対処は仕様的な決定が必要になる
> 出した例に意味がない
レスする前にちょっと良く考えてみて。
仕様的な決定が必要にならない例って
あるのか？
>>115 落ちるしかないような制御パスならいいけど、
ファイルが無い程度で例外出されたらたまらない。
>>119 try catchでファイルがない時の処理を書けばいいだけでは？
>>122 お前は見事に黙った（反論しなかった）なｗ
０徐のチェックなんてそもそもコードがおかしいじゃねぇか
ファイルが無い場合のエラー処理を追加するくらいなら、
>>121 戻り値のチェックをするのは面倒だけど、try catchブロックを書くのは厭わないというわけか。
>>125 > 欧米さんのプログラムなんて、あるべきファイルが無かったら
> うんともすんとも言わなくなるのが多いぜ。
それ、例外を使ってないからだな。
０徐の前に分母が０に近いか０かどうかをチェックするけど
>>128 そうかもな。
だがエラー処理のコストは馬鹿にならないから、
戻り値を無視するのが欧米流。
ファイル用意してないやつが悪いんだし。
>>127 戻り値のチェックの場合は、
たとえば、ファイルを開く時、
ファイルがないというエラー以外に、
その他のたくさんにエラーコードに対処しないといけないからね。
例外だと、その他のエラーをすべてまとめて処理することができる。
>>130 アメリカ流じゃなくて、
クソコード＝戻り値を使っている。
では？
C言語しか知らない時点で
ファイルを用意しろって仕様に対してファイルを用意しない奴。
>>131 ファイルオブジェクトがNULLかどうかチェックすればいいだけ。
ほんっと頭の固い馬鹿だな
２８日のバトルは戻り値側の圧勝だったな
吹いた
勝利宣言(笑)
おまいらすみません。
>>140 WEBアプリもバッチファイルも変わらん。
バッチファイルも、途中で処理がエラーに成ったら
途中で中断しないといけないし、
WEBアプリは、リクエストが途中でエラーに成ったら
そのリクエストはやっぱりそこで中断しないといけない。
GUIアプリは、ユーザーのクリックで処理が開始され、
その途中でエラーに成ったら、処理は中断
どのアプリにも共通なのは、処理が途中でエラーに成ったら
途中で中断しなければならないということ。
処理が続けられるのは想定内の一部のエラーだけ。
信頼性が高いシステムに要求されるのは
>>142 一番外でcatchして何ができるというの？
結局、ユーザーに通知、またはシステムを落とすあたりで妥協するでしょ？
戻り値にしろ例外にしろ、エラー時に正しく処理をしなければ
信頼性が高いシステムは作れない。
>>143 エラー時に正しく処理をするなんて、当たり前の前提なのでは？
このスレ見る限りその前提すら認識できていないやつも多いけどさ。
>>144 そうね。とくにUIのあるアプリケーションのプログラミングなんて
コード全体の8割がエラー処理みたいなもんだよね。
>>143 > 戻り値にしろ例外にしろ、エラー時に正しく処理をしなければ
> 信頼性が高いシステムは作れない。
当たり前。
で、その当たり前のことをやる場合のコストを考える。
なんども戻り値厨が言ってるように、
戻り値では「コストが高いからエラー処理を省く。（例 printf）」
まあ、このような手抜きが当たり前に行われているんだ。
だけど、例外だとコストを上げずにエラー処理を行える。
>>143 > 一番外でcatchして何ができるというの？
たとえば、Wordだと文書を編集中に
「装飾ボタン」を押してその処理にバグがあって
画面に「内部でエラーが発生しました」と表示する。
だけどシステム（Word）は落ちずに、別の処理を行える。
データが消えなくてすむ。
まあ、こんなことができるよ。
戻り値で戻して来る場合って
そもそもの話。
戻り値マンセー君はエラー処理をなるべく手を抜きたいと言ってるようにしか見えん
バグなんだから起きたときに不正な動作をして、システム・データを
GC なし言語で自分でメモリ管理するようなもんで、戻り値派でも
Windowsの小物アプリばかり作ってると想定外の例外即アボートなので例外のほうが楽かも
そもそもスレタイがこうなのになんで例外と戻り値の戦いになってるんだ？
もともとふっかけてきたヤツの論調が
所詮バカはなにやったってバカ
自分が馬鹿じゃないという自信があるなら例外を使えばいいんじゃない？
>>157 というかさ、例外ってのはC言語の時代にはなく、
C++も最初搭載されてなく、その後で追加され
そして最近できた言語にはもれなく付いている機能なんだよ。
馬鹿かどうかで例外を使うとかじゃなくて、
例外を使おうかどうか悩むまでもなく
すでに今は例外を使うことが当たり前。
使えてあたりまえだし、使いこなせなければ、
それこそ馬鹿の烙印を押される。
つまり例外すら使えない馬鹿は淘汰されろというのが例外に込められたメッセージなわけで、
良い悪いよりも使用禁止されてるんだろ？例外って。
オブジェクト指向もぶっちゃけセミナー御用達言語で
使用禁止されてないけど？
googleさんのとこでは駄目だってね
それはGoogleの話だろｗ
ところで、禁止かどうかの話と、正しく使えるかどうかの話は全く別物じゃない？
正しく使えるならその危険性も熟知しているだろうし推奨はしないだろう。
お前のほうがDQNに見えるｗ
C++標準ライブラリなんかも例外使ってるからなぁ。
ライブラリならいいと思うが。
何がスルーされるか保証されないことがそんなに問題か？
>>170 ・設計時に考慮するべき項目が増える
・試験パターンが増える
・メンテナンスコストが増える
・めんどくさいからと自分とこで握りつぶす奴がいる
>>171 設計時に何を考慮するのさ？
なんで試験パターンが増えるのさ？
なんでメンテナンスコストが増えるのさ？
例外なんて、すべてエラーとして扱えばいいだろ。
エラーなんて一種類だよ。Exception型一種類。
戻り値で言えば、どんなエラーでもfalse返すのと同じ。
エラーを区別したい時だけ、考えればいいだけ。
ほらこういうのがいるから。
反論できないから一言で済ますわけか。
言おうが言うまいがそれはどうでもいい。
>>173 に反論がないという事実に何も変わりはないから。
ここで想定外の例外が発生したときにどう動くのかとか聞かれない現場は楽でいいね。
>>178 そのときはシステムが落ちる。
落ちるのでどの段階で回復させるか書かないといけない。
そうやってシステムが満足に動くようになるまで個別に例外を捕捉し続ける。
Exception一択なんて例外を正しく使えないことを自白しているようなもの。
>>179 その分コストかかるよね。
「落ちます」「握りつぶしてるから大丈夫です」以外の答えを用意しようとすると。
>>180 システムが落ちるかどうかは作り方次第だろ？
お前難しく考えすぎ。
処理を小さい単位で考えないからそういう事になる。
関数はすべて実行されるか、全く実行されないかの
二つの状態になるように作ればいい。
トランザクション、原子性という考え方だよ。
それを満たすように作れば、簡単に回復したいタイミングで
回復させることができる。
>>181 戻り値でやろうとするとコストがかかるが、
例外だとコストはかからない。
ソレは戻り値でもかわらんだろ…とこーやって延々ループしてるだけじゃねーか。
想定外のエラーで「落ちます」と「握りつぶします」以外に対処のしようなんて無いだろ
>>182 > 戻り値でやろうとするとコストがかかるが、
> 例外だとコストはかからない。
なぜ？
>>184 「想定外のエラー」と「想定外の例外」は違うんだな。
ま、エラーの時だけ例外を投げるようにするんならまだいいんだけど。
>>184 だから、文字通りの「例外」でいいんじゃない？
想定外だったらログ出して落とすか無視して続けるかしかない。
例外にビジネスロジック入れようとするから混乱する。
ビジネスロジックを除けば例外の大半は事前に入力値をチェックするだけで
>>185 関数内でエラーが発生したらエラーが発生したという情報を
親の関数に返さないといけない。
だから大抵の関数は、戻り値としてエラー値を返すことになるから
エラーを戻り値に混ぜるかしないといけない。
（例 たとえばこの関数は正の整数しか戻り値に使わないからマイナスをエラーコードにする等）
関数ごとに何の値をエラーコードとして使えるか違うし、
汎用的にエラーの値を返す方法がない。
つまり、実際の関数がそうなっているが、どういう値を返したらエラーなのか
関数ごとに調べる必要があるし、関数ごとにエラーの処理方法も違っている。
そして関数で起きたエラーコードを親に返すわけだが、またそこでどんな値で
返すか悩むことになる。
エラーコードをどうやって返すか考えるコストがかかるし、
そのエラーコードを解釈するのにもコストがかかる。
統一的なやり方がない。
でもそれじゃ例外の意味なんてないよね。
必ずあるはずのリソースが存在しなかった、
例外にしたってこの事象はどんな例外にするか設計はいるんだし。
>>189 だから、その設計に時間がかかるんだよ。
事実、関数ごとにエラーの値をどうするか違っているだろ。
関数ごとに違ったエラー処理を書かないといけないし、
もちろん関数ごとにエラー処理を書かないといけない。
まとめることができるエラー処理をまとめることもできない。
>>191 リソースの存在をチェックするとかリソースがない場合の処理とか
手続き型のビジネスロジックに条件分岐がないのはまれだと思うが。
思考停止して帰り支度をする「例外」的なのは困るだろ。
>>194 > 例外にしたってこの事象はどんな例外にするか設計はいるんだし。
どんな例外だろうが、例外を返すときに関数の戻り値の
型を考えなくてすむ。
たとえば、文字列を返す関数の戻り値に
エラーコードをどうやって混ぜ込む？
>>195 例外だって設計はいるだろ。つかそうじゃなきゃ例外を自分で定義する意味がねーよな。
>>196 > 思考停止して帰り支度をする「例外」的なのは困るだろ。
なんで？
戻り値だって、リソースが確保できなければ、
帰り支度するだろ。
>>197 戻り値、戻り値とは言うけれど、どうしても戻り値で渡せないなら、
引数にエラーコード受け渡し用の変数ポインタを持たせるなんて強引な手もある。
>>200 てか、C標準関数には引数に結果格納用の変数ポインタ渡して、戻り値はエラー専用とかいうのがあったような
>>198 > 例外だって設計はいるだろ。つかそうじゃなきゃ例外を自分で定義する意味がねーよな。
例外の場合は、例外の設計と戻り値の設計が分離されている。
だから例外の設計をするときに、戻り値の設計は不要。
もちろん例外を使っていれば、逆に戻り値の設計をするときに例外の設計は不要。
戻り値にエラーを混ぜ込む方法を考える必要がないんだよ。
>>197 だから、誰が例外はイラネ全部戻り値でやれっつてんだよｗ
例外も戻り値も使い分けりゃいいんじゃね？つってんだよ。
>>200-201 そう。それも例外がない場合の、エラーを返す方法の一つ。
戻り値の場合は、エラーを戻す方法が戻り値と分離されてないから
そのように、いくつかの方法を使う必要がある
実際関数ごとに違っている。
だから、関数ごとに個別対応が必要なりコストがかかる。
んだな。Cにはerrnoとかがある。
>>203 > だから、誰が例外はイラネ全部戻り値でやれっつてんだよｗ
> 例外も戻り値も使い分けりゃいいんじゃね？つってんだよ。
戻り値厨だろｗ
例外でもライブラリが違えば同じことだろ。
>>205 Cの場合、errnoをいちいち見ないと
発生したエラーがなにか具体的に分からないから
それも大変だよな。
errnoごとに処理が違ってくる。
なにをcatchするかとどこが違うのよｗ
>>204 例外使った場合も、戻り値でエラー判断しなくてすむわけじゃないし。
>>207 あんたが言ってるのは、ライブラリによってエラーの値が
違っているってことだろ？
ここで問題にしているのは、そのエラーの返し方。
例外を使っていれば、ライブラリが違ってもエラーの返し方とその取得の仕方は統一されてる。
Cのように、
・エラーコードを返す。
・true/falseを返す。
・NULLポインタを返す。
・引数でエラーを返す。
・戻り値はエラーを返すのに使って、計算結果は引数で返す。
・errnoというグローバル変数で返す。
のようにいろいろ分かれてることはないよ。
だからソレは設計の問題だと…
213 ：
211 ：2011/01/29(土) 22:06:07
さらに関数の中で関数を使用している場合、
例外の場合、何を例外にするかが決まってないから。
>>212 だから、その設計に時間がかかるだろ。
たかがエラーを返す方法ごときで
考える必要がある時点でおかしい。
>>213 おまえさんが例外を正しく使えないのはよくわかった。
>>214 話についていけてないならレスするなよ。
今話しているのは、エラーの値を何にするか（例外の型をなんにするか）
ではなくて、その決まった値をどうやって返すかって話だよ。
>>214 そういえばそうだったな。
別にオブジェクトである必要すらなかったんだな。
>>213 そもそも関数のユーザとしてはtrueかfalseかを知りたいんで、
エラーの内容を知りたいわけじゃないんだよね。
もしエラーが発生したらちゃんと処理してtrueかfalseにして返してくれ。
>>216 また、反論がないね・・・
>>219 > そもそも関数のユーザとしてはtrueかfalseかを知りたいんで、
お前がture/falseが知りたいだけであって、
他の人は詳細なエラーを知りたいこともある。
>>220 じゃあ、今からその話をしようぜ。
ここで問題にしているのは、そのエラーの返し方。
例外を使っていれば、ライブラリが違ってもエラーの返し方とその取得の仕方は統一されてる。
Cのように、
・エラーコードを返す。
・true/falseを返す。
・NULLポインタを返す。
・引数でエラーを返す。
・戻り値はエラーを返すのに使って、計算結果は引数で返す。
・errnoというグローバル変数で返す。
さらに関数の中で関数を使用している場合、
たとえば、true/falseでエラーを返す関数で、
エラーコードを返す関数を使用していると困ることになる。
関数内では詳細なエラーが分かっても、
true/falseでエラーを返す関数からは
詳細なエラーを返すことができなくなってしまう。
>>221 他の人は詳細なエラーを知りたくないこともあるってことは思いつかないのか。
>>223 つまり、知りたいことも知りたくないことも両方あるってことだろ。
じゃあ、両方に対応できるようにしないといけないね。
例外を正しく使えないのに例外マンセーなのも笑える話。
>>213 だからと言って例外なら何でもスローして良いなんて話になるわけでもないでしょ。
かっこ良く（笑）いうと、戻り値だとエラーの返し方が統一されてないから、
設計のマズさを戻り値の欠点みたいに言われても困る
だから、それでいいじゃん。
>>224 なんでお前の都合にあわせないといけないんだよｗ
バカが自分のバカさ加減を証明してるだけ。>例外イランってこのスレで頑張ってる奴
>>229 関数ごとに戻り値の型が違う以上、
それを統一的に扱える設計なんて存在しないよ。
自分で作った関数だけなら不可能ではないかもしれないが、
他のライブラリを使えなくなる。
>>233 戻り値でエラー通知するライブラリが存在しないわけでもないでしょ。
自分だけ例外使ってても、そういったライブラリと付き合わないといけなくなった時点で
その統一制は崩れ去る。
>>232 例外いらんとか言ってる奴いるか？
何でも例外ですまそうとする、例外を正しく使えないプログラマはいるみたいだけど。
戻り値しかない言語で、エラーの返し方を統一する方法としては、
もはや宗教だな。キモイ。
>>232 正しく使えてない知ったかの癖に馬鹿じゃないと思ってるやつを炙り出すためなら喜んで馬鹿になろう。
このスレにも散見されるが
catchすべき例外と、そうでない例外ってあるよね。
>>234 > 戻り値でエラー通知するライブラリが存在しないわけでもないでしょ。
いろいろ存在するってのはわかってるから、
ちゃんと例に出しただろｗ
Cのように、
・エラーコードを返す。
・true/falseを返す。
・NULLポインタを返す。
・引数でエラーを返す。
・戻り値はエラーを返すのに使って、計算結果は引数で返す。
・errnoというグローバル変数で返す。
で、統一されてないから、その処理方法を関数ごとに書くことになって
コストがかかるという話をしてる。
さらに関数の中で関数を使用している場合、
たとえば、true/falseでエラーを返す関数で、
エラーコードを返す関数を使用していると困ることになる。
関数内では詳細なエラーが分かっても、
true/falseでエラーを返す関数からは
詳細なエラーを返すことができなくなってしまう。
一行でも多く書くのをコストコスト言うバカがいるのはたしかだな。
>>239 > ぬるぽとかOutOfMemoryみたいなコーディングミスに起因する例外はデバッグ情報であって、
ぬるぽはともかく、OutOfMemoryはコーディングミスとは限らないぞ。
純粋にメモリが足りなくなって、処理ができないって場合もある。
だからってアプリを落とせばいいというわけじゃない。
なぜならマルチタスクなら他のプロセスを終了すればメモリは空くから。
>>241 その一行も、関数ごとに書かないといけないなら
二倍のコストになるよ。
屑レス量産してるお前のコードが一番コスト悪そうだが。
うむ。どうやらこれで
>>240 とりあえずtrue/falseでエラーを返す関数の仕様変更からはじめようぜ。
エラーの表現能力が足りないとわかってるんだから当然だろ。
戻り値方式は戻り値だけでいいが、
>>246 > とりあえずtrue/falseでエラーを返す関数の仕様変更からはじめようぜ。
例外を使うことにした。
その仕様変更は必要なくなった。
完
例外は無限の表現能力があるからなぁ。
>>249 のようにエラーさえあれば何でも例外にして投げてしまおうなんて言う奴がいるので、
「どんな例外が飛んでくるか把握しきれない」などというアンチを生み出すことになる。
いっそ全部voidにしようぜ。
>>250 戻り値でオブジェクトや構造体返せば済むだけの話。
どんな例外が来ようが「適切な」実装をしとけばいいだけちゃうん
>>250 それがメリットだと思ってるところがレベル低すぎる
>>253 戻り値にエラーを混ぜるためだけに
戻り値の型を変更するなんて馬鹿らしい。
それにそんなことをすると int ret = foo(bar()) なんて
使い方が出来なくなると書いたろ。
たかが戻り値のエラーごときに、システム全体に
DQNな仕組みを採用したいのか？
>>254 俺の作った関数の例外はまったく同じ内容でも異なる型の例外が１００個ある
もちろん将来的には違う内容にする見込みだからちゃんとcatchしてくれ
構造化例外があるくらいだから、いっそtry~catchだけ使ってifレスでコーディングするかｗ
>>257 try {
リソース確保
>>257 が作った関数
} catch (Exception e) {
何かする必要があればそうぞ
} finally {
リソース解放
}
>>258 俺の作った関数の戻り値はまったく同じ内容でも異なる値の戻り値が１００個ある
この場合でも大変だよな？
リソース解放で例外が出そうだなｗ
262 ：
260 ：2011/01/29(土) 22:52:45
>>261 C言語のfcloseでもエラー返すから、そのツッコミは意味が無い。
rand()はタイヘンだぁ
>>265 fcloseってのはリソース解放のことね。
そのリソース開放でエラーが起きたら
どうする？
例外が出るんじゃないのかｗ
C言語のfcloseの話だよ。
C言語にはtry~catchあんの？
>>266 そのfinally句で解放する予定だった他のリソース解放を継続させて、終了。
try {
リソース確保
>>257 が作った関数
} catch (Exception e) {
何かする必要があればそうぞ
} finally {
try {
リソース解放
} catch (Exception e) {
何かする必要があればそうぞ
}
try {
他のリソース解放
} catch (Exception e) {
何かする必要があればそうぞ
}
}
そうぞは直した方がいいとおもうぞｗ
握り潰す前提で例外使おうとしてる人は正しいの？
C言語のfcloseでも同じだけど、
>>274 それは、どう考えるか次第だね。
どの方法を使うにしろ、例外ならやろうと思った方をやれる。
だけど戻り値だと、すべてのfcloseにエラーチェックを入れなければ
いけないならコストがかかってしまうから、
ついコーディングミスなんてしないよ。
だからfcloseでエラーチェックは不要。なんて考えてしまう。
>>273 握り潰してるって、どれが？
finallyでリソース解放しようとして失敗した場合、
具体的にどんな回復処理をする？
まずは他の解放可能なリソースを解放するのが最優先だろ。
そういうのを無視していいための例外。コストがかからない(ｷﾘｯ
メモリリークなんてバグじゃないって主張する同僚みたいなもんだな
あと、落ちてなければバグじゃない。もよくある。
>>277 実際、もしfclose()を今時の言語で例外アリで実装するなら、
返り値はvoidで、close失敗したら例外を投げるだろ
それともcloseする箇所全部で返り値チェックしたいわけ？
だから、常識的にはfopenできたらfcloseすんじゃ？
例の戻り値厨がいないと静かだなｗ
戻り値厨と例外厨しかいないこんな世の中じゃ
エラー処理と例外の区別がつかい人が沢山いるね。
>>285 > CPUがサポートして、OSがサポートした環境下での言語でしかサポート出来ない。
それは CPU 例外の話だね。
このスレで話してるのは C++, Java, Python, Ruby, ... あたりに組み込まれた
言語機能としての例外ね。
一般化するとこうなる。
http://en.wikipedia.org/wiki/Exception_handling > ... exceptions, special conditions that change the normal flow of program execution.
言語機能としての例外はハードウェアや OS のサポートは何も必要としないし、
そもそもエラー処理に使われることを想定しているよ。
たまに病気持ちが議論に入ってくるよねｗ
どっちも馬鹿じゃね？エラー処理も含めてプログラムの流れだよ。
でもそのエラーが出たときの対処にも仕様があるでしょ？
>>290 > どっちも馬鹿じゃね？エラー処理も含めてプログラムの流れだよ。
通常（正常）時のプログラムの流れの話してるんだよ。
お前が言ってるのは、登山コースから外れても、
それも含めて道だ。と言ってるのと変わらんｗ
>>291 エラーが出ないときの処理・・・通常の流れ
エラーが出たときの対処・・・通常ではない流れ
と一般の人は考えててるだけの話。
お前の仕様書にも、「エラーが出たときの対処」と
仕様書からして区別して書かれてあるんだろ？
サイコロを振って1が出て欲しい時に1以外、2～6までの目が出る事がプログラム上で言う「例外」。
> サイコロを振って1が出て欲しい時に1以外、2～6までの目が出る事がプログラム上で言う「例外」。
>>294 サイコロを振れば1～6のいずれかの数字が出る事は容易に予想がつく。
というか、そういう仕様。
この場合に、ランダムな値を出すためにハードウェア乱数生成器（そういうハードがある）を
使っていたとして、その乱数生成器が物理的に壊れていて、ランダムな値を出せなかった。
この場合に発生させるのが、例外です。
if (!f()) { エラー処理 } と try {f();} catch(f_Exception() e) { エラー処理 }も対して変わらない。
何が例外かなんて仕様と設計と気分で決めるもの
それだとぬるぽは例外じゃないってことか
>>297 でもその場合の対処が仕様書に書かれていれば
俺はその場合は例外は出さないな
（例：壊れている場合は「３」を使う等）
「サイコロを振って１～６を出す」関数で１以外が出るのは例外にしないほうがいい。
>>302 ぬるぽは、ポインタにNULLが入ったときに発生する例外ではなく
ポインタにNULLが入っているのに、そのポインタを参照してメソッド呼び出しなんかを
したときに発生するものではす。
基礎的なところで間違えて変なことを言うから
お前の説得力がどんどん下がる。
>>303 > （例：壊れている場合は「３」を使う等）
使えないサイコロだなｗ
>>304 >「サイコロを振って１を出す」関数で１以外が出るのは例外にしても悪くない。
俺が言いたいのはつまりそういう事だ。
だからこそ「サイコロを振って1が出て欲しい時に」と言っている。
>>297 はその辺を理解していない。
条件分岐と例外の違いみたいな話になってきたな
関数の仕様として、「戻り値は○○を返す。ただしエラーの場合には××を返す」などという
>>307 「サイコロを振って１を出す」関数
と
「サイコロを振って1が出て欲しい時に」
は全然意味が違うだろｗ
>>307 > 俺が言いたいのはつまりそういう事だ。
あ、そういうことだったの？
つまり、
>>294 は常に1しかでない関数の話をしていたのかｗ
それなら問題ないよ。
「サイコロを振って１を出す」関数というのは、
常に1しかでない関数の話だからね。
常に1しか返さない関数でエラーだの例外だの出されたらたまったもんじゃないな
「例外を出すのも仕様の内」だから
>>297 の説得力が正直微妙
>>312 じゃあ、エラーの時はどうするんだよｗ
エラーの時、何を返すかの話をしてるんだが、
ついてこれてる？
エラーが出るはずがないというのは論外な。
エラーが出る前提の話をしてるんだから。
>>314 エラーが発生したら内部で処理してくれ。
>>313 > 「例外を出すのも仕様の内」だから
>>297 の説得力が正直微妙
なんで？
例外を出すのも仕様なのはあたりまえだろう。
>>315 内部で処理できないエラーの話をしてるんだが。
お前本当に、ついてこれてないんだな。
これでやっとスタートラインにたてたか？
もう一度復習すると、
戻り値として1を返す関数で、
内部で処理できないエラーが発生した場合に
何を返すのかって話をしてるんだぞ。
>>317 内部で処理できないエラーを伝えられてもどうしようもないけどな。
>>318 たとえば、fopen関数は内部で処理できないエラーを返すけど、
何も出来ないというの？
>>286 OSやCPUが理解出来ていないみたいだね。
>このスレで話してるのは C++, Java, Python, Ruby, ... あたりに組み込まれた
>言語機能としての例外ね。
16bit時代のC++に例外機能がなかったのは何故か？
OSが32bitになってからいろいろな言語で例外機能が追加された理由は？
32bitで追加されたのはマルチタスク・マルチスレッドだけじゃないんだが。
>>289 >あと、どこでもいいからLinuxのカーネルのソース見てみgoto多用されているから。
>これらは「エラーが発生したから、通常のプログラムの流れを切断する」ために用いられている。
>goto分完全禁止の時代は終わってね、今は例外処理の代わりとしては使ってＯＫの時代なんだよ。
まさかLinuxのカーネルがgoto文使っているからgoto文は使って良いとは、どんな思考回路なんだ。
まっ自分で使うのは勝手だが、他人には強要するな。
戻り値で伝えていたエラーを例外に置き換えることは可能。その逆も可能。
>>320 > 16bit時代のC++に例外機能がなかったのは何故か？
あったよ。
反論終わり。
>>182 > 関数はすべて実行されるか、全く実行されないかの
> 二つの状態になるように作ればいい。
もうちょっと考え方を進めて、処理に成功したかどうかだけを教えてくれ。
詳細な失敗理由が必要なら後から参照するから。
っていう風には考えられないのかな。
>>323 なら、特定の関数が出す正規の例外には共通のベースクラスを継承させるようにするか
>>323 それをしようと思うと、グローバル変数が必要になるから
マルチスレッドで面倒。
>>319 どんなfopen使ってるんだよ。
うちのfopenは処理できなきゃ単にNULLが返ってくるだけのお利口さんだぞ。
ほらエラーの値としてNULL返してるじゃんｗ
>>320 お前、自分の知らないことは存在しないとでも思ってるのか？
少しは Web 上の資料を漁ってソースを確認してから書き込むようにしてみろ。
>>328 C言語はオブジェクト指向じゃないよ。
C言語以外のオブジェクト指向は
言語の標準ライブラリからして例外を使ってる。
だから、詳細な失敗理由を後から参照とか
そういうやり方しなくていいんだよね。
ぶっちゃけ、このスレの戦いは、
C言語しか知らないやつ VS オブジェクト指向言語を知ってるやつ
の戦いになってる。
だから、たまにCPU例外の話をしたり、日本語としての例外の話をしたり
そういう、わかってないやつが出没してる。
ま、基礎知識の差が明らかにでてるね。
>>320 に反論する場合、例外がハードやシステム寄りの機能であることはどうでもよくて、
例外がプログラムのフローをめちゃくちゃにするという主張を突っつくべきなんだよ。
「exit()は使うな。終了するときいはmainまで処理を戻せ(returnしろ)」みたいな話は確かにある。
throwはcatchしなければエラー情報つきexit()みたいな動きをするから、それに対して警戒するのは当然だろう。
ここでは関数呼び出ししか考えられない人が多いんだな。
> 「exit()は使うな。終了するときいはmainまで処理を戻せ(returnしろ)」みたいな話は確かにある。
>>332 ポリモするからどんな例外が飛んでくるのかわからないって話なら、それは設計がクソとだけ言っておこう。
>>332 それはお前が未熟なだけだよ。
なぜなら、各言語設計者や標準ライブラリ開発者は
よく理解しているわけだが、そういう人が
例外を使っているだろ。
例外を否定するというのは、言語を否定していることそのものだよ。
>>334 ポリモを否定すると、はっきり言ってオブジェクト指向のメリットの大半を
享受できないわけだが。
>>336 誰もポリモ否定してない。
個々の具象クラスが思い思いに独自の例外を飛ばす設計がクソ。
>>337 > 個々の具象クラスが思い思いに独自の例外を飛ばす設計がクソ。
安心しろ。どの例外もExceptionのサブクラスだ.
どんなサブクラスであっても、スーパークラスとして
処理できるのが継承の利点だろう。
>>337 だから、処理できないエラーが出たからといって例外投げずに
内部で処理してインタフェースどおりの挙動をしてくれと言っている。
>>339 関数内部で処理できないエラーがあることを知らないのか？
だからこそ、戻り値でエラーを返すんだろ。
>>338 ということで、あちこちで握りつぶしコードが量産されるわけだな。
>>340 あぁ、言葉が足りなかったな。
インタフェースとして規定されている戻り値なり例外ならいいよ。
それ以外のことを考えさせるな。
>>341 正しい例外のやり方を知らないんだな・・・
Exceptionは捉えたら必要な処理をして、
正常な状態に戻すかそれができない場合は、
再throwするわけで、
握りつぶすのはお前だけ。
あちこちで握りつぶしコードが量産してるのは
お前だけ。
>>344 あちこちで例外捉えるコードを量産しないといけないのは変わりないね。
>>343 インターフェースとして規定されてない戻り値や例外ってなんだよ？
その例外をお前はなんで考えるんだ？
お前、自分で無駄なことをして自滅してないか？
>>345 それは、あちこちで戻り値のエラーチェックするコードを
量産するのと何が変わらないんだ？
お前が何を否定しているのかサッパリわからん。
>>333 例外投げっぱなしできちんと終了できるのって
スコープ抜けたらリソースが自動的に解放されるように徹底してる場合だけだよね。
>>348 リソースが自動的に解放されるというのが
なんか誤解してそうだが自動的に解放されないなら、
例外発生時にfinallyで手動で解放もできる。
で、それは置いといて、スコープ抜けたときにリソースが解放されてない関数が
戻り値でエラーを返していたら、きちんと終了できるとでも？
リソースが解放されない問題は、例外でも戻り値でも同じことだろ。
そもそも議論にならんのだよ。
オブジェクト指向言語を知っているからといって例外の正しい処理方法が分かっているとも限らないが。
>>346 オブジェクトの作成者がtry-catchし忘れるだけで、簡単に漏れてしまうから
自衛するしかないという面もある。
>>322 ,329
嘘を書くな。
あるソースを出せるのか？出せないだろうが。
354 ：
仕様書無しさん ：2011/01/30(日) 16:00:39
エラーに対するケアはエラー発生直近で行うのが原則。
例外初心者がよくやる勘違いは、
>>354 > エラーに対するケアはエラー発生直近で行うのが原則。
例外を理解していないものが勘違いすることの一つが、
catchがなければ、遠くに飛ぶから、
遠い場所でエラー処理をしなくてはいけないと思うこと。
たんにcatchすれば、次の行で処理できるのだから問題ないし、
例外は遠くに飛ぶのではなく、実行中の関数を異常終了させてりだけ。
その連鎖で遠くに飛んでいるように見えるだけで、
実は遠くになんか飛んでいない。
必要があれば必要なところでエラー処理を行える。
そういや、今でもuclinuxのような
catchの中で再throwした例外はどこに飛ぶのかな？
そりゃ呼び出し元関数だろｗ
へぇ
なるほどぉ
>>358 catchし忘れたら遠くに飛んでっちゃうじゃん。
>>356 それだと俺には分からんが？
具体的にどの製品がどのOSに対応したか書いてくれ。
>>357 >Turbo C + +3.0 will bring its low-end DOS product to conformity
>with the ANSI and AT&T C+ + 3.0 specification, including support for templates and exception handling,
だから、それが16bit環境で例外処理が出来ると何処に書いてある。
Turbo C ++なら
http://edn.embarcadero.com/article/33626 >Turbo C++ 4.0J for DOS［1995.4～、PC-9800シリーズ&DOS/V両対応］
>プロテクトモードで動作し、充実した機能を持つ統合開発環境をサポート。
>テンプレートや例外処理、実行時型情報などのC＋＋機能、オプションの Borland PowerPack for DOS16と組み合わせて
>プロテクトモードアプリケーションの開発にも対応している。
>PC-9800シリーズとDOS/Vの両方で動作するライブラリや両機種用のTurbo Debuggerが標準添付されている。
この意味が分かるか？
>プロテクトモードで動作し
と書いてあるだろう。16bit時に例外処理が出来るのか？アホだろう？
ちゃんと調べて書けよ。
>>364 catchすれば遠くに飛ばないだろ。
return、returnの連鎖で遠くに行ったとしても
それを遠くに行ったとは言わないように、
例外で呼び出し元関数に戻って、
そこからさらに呼び出し元関数にもどったとしても
それは遠くに飛ぶとは言わん。
>>364 > と書いてあるだろう。16bit時に例外処理が出来るのか？アホだろう？
うん。uClinuxとかできてるよ。
それに、16bit CPUにもCPU例外機能は搭載されてるんだ。
お前は32bitでなんの機能が搭載されたと言いたいのかな？
368 ：
356 ：2011/01/30(日) 17:24:47
>>365 > 具体的にどの製品がどのOSに対応したか書いてくれ。
「16bit時代のC++に例外機能がなかった」に対して
えらく昔から C++ に例外機能があったことを示しただけだよ。
実装の歴史は情報が少なくてよくわからない。
で、君はハードウェアのどんな機能が C++ 例外処理の実装に
必要だと言うの？
こういうの不遜メソッドっていうんだってな。
>>361 みたいなのがいる限り例外の使用は推奨できない。
>>365 たのむから、
プログラミング言語上の例外とCPU例外の区別ぐらいは
つくようになってから出直せカス
>>361 じゃなくて、より外側の例外ハンドラな。
>>373 そのとおり。
呼び出し元の関数ではない。
>>365 コンパイラの動作環境とコンパイルしたプログラムの動作環境との区別もついてないな。
>>367 >うん。uClinuxとかできてるよ。
それが言語なのか？OSと言語の区別もつかないとは、アホだろう。
>それに、16bit CPUにもCPU例外機能は搭載されてるんだ。
>お前は32bitでなんの機能が搭載されたと言いたいのかな？
お前は馬鹿か？言語の例外機構とCPU例外も区別が付かないのか？
早く16bit環境で例外が実装出来る言語を言えよ。アホ。
>>368 >「16bit時代のC++に例外機能がなかった」に対して
>えらく昔から C++ に例外機能があったことを示しただけだよ。
それは例外機構なのか、単純に例外処理が出来るだけのことを言っているのか？
>で、君はハードウェアのどんな機能が C++ 例外処理の実装に
>必要だと言うの？
自分で調べろ。
>>371 >プログラミング言語上の例外とCPU例外の区別ぐらいは
>つくようになってから出直せカス
アホ。区別がつかないのはお前だ。
>>375 >コンパイラの動作環境とコンパイルしたプログラムの動作環境との区別もついてないな。
いいから、16bitの動作環境で例外処理が実装出来る言語を言えよ。
お前ら、本当に知識がないな。
>>376 > いいから、16bitの動作環境で例外処理が実装出来る言語を言えよ。
Java2MEとか、16bit CPUで動作するしほとんどのJava例外も実装している。
16bit時代の処理系という縛りで挙げても、
Adaとかmodula-2とかの現代的な言語の処理系は
例外処理を実装していたものが色々あったぞ。
例外なんて商用プログラムじゃ利用禁止が
あのさ。横から失礼するけど
いや、ココは戻り値マンセーの馬鹿をオモチャにして遊ぶスレですけど…？
例外を正しく使えない例
>>383 いや、それはアリだろ。
戻り値とかグローバル変数でエラー情報を伝えてくるライブラリを利用するときなんか特に。
385 ：
384 ：2011/01/30(日) 19:22:38
>>384 グローバル変数を、スレッドローカルな変数に読み替えてくれるとうれしい
例外のスタックトレース機能も利用できるしな。
いや、それどころか16bit初期のPANAFACOMのCAS BASICからして
Cしか知らんおっさんはまさに老害だなｗ
実は
>>361 みたいな知ったかを燻り出すためのスレなんだ。
例外を正しく使えるプログラマばかりならば和解は可能だ。
>>376 > いいから、16bitの動作環境で例外処理が実装出来る言語を言えよ。
だから、g++だよ。
16bit LinuxのuClinuxで動くだろ。
>>389 じゃあ、その証拠に
「戻り値厨はこのスレからされ！」って
言ってみ。
そう。それが戻り値を使ったエラーの返し方な。
>>383 if (error) {
new ごらごらException(error);
}
///
あとで、errorの中身が分からんと困るかもしれんので、errorぐらい入れてほしい。
あと、RuntimeExceptionだと一般的すぎるから、もう少し限定してくれや
いや、だからCしか知らないと言ってる奴でlongjmp知らないのがいるとは思えないんだが。
>>394 知らない人多いよ。
標準関数が戻り値でエラーを返しているから
そういう使い方があることに気づかない人が多い。
>>376 それはMac用か？
それなら、MC６８０００は内部アーキテクチャが32bitだ。
>>378 >Java2MEとか、16bit CPUで動作するしほとんどのJava例外も実装している。
具体的なCPUは？
>>380 それページから動作環境に移動するとこれが書かれているが。
>動作環境
>IBM PC/AT互換機（WindowsR 7, Windows VistaR, WindowsR XP, WindowsR 2000）
>>387 >いや、それどころか16bit初期のPANAFACOMのCAS BASICからして
>EXXCEPTION SECTIONなる例外処理はあった。
ミニコンなら実装されていてもおかしくない。
>>390 >だから、g++だよ。
>16bit LinuxのuClinuxで動くだろ。
CPUは？
お前らいまから、新人でもしっている事を説明してやるよ。
コンピュータは言語が直接動いているわけじゃなく
マシン語が動いているんだ。
だから、マシン語で動かせるものしか実行出来ない。
例外がマシン語レベルで対応していないCPUなら実装出来ない。
当たり前のことだ分かったか？
言語の例外機構がCPUに関係ないとか言ってたら新人に笑われるぞ。
>>396 別にお前の言うことが正しかったとしても
俺等別に言語やＣＰＵにこだわって話してないのがわからないのか？
邪魔だからさっさとうせろ
育ちと頭の悪い奴相手にするの嫌なんだ
空気読んでくれない？
>>391 まだ気付かないのか。
ターゲットは最初からお前だ。
>>396 ミニコンならなぜ実装されていてもおかしくないんだ？
さすがにわざとだろこれは。
>>396 > お前らいまから、新人でもしっている事を説明してやるよ。
> コンピュータは言語が直接動いているわけじゃなく
> マシン語が動いているんだ。
つ VM
つか、例外がマシン語レベルで対応できないCPUってあるのかｗ
>>404 CPU例外と、言語が提供する例外が同一である保証は無い。
>405
>>397 >俺等別に言語やＣＰＵにこだわって話してないのがわからないのか？
俺はこだわっていないが、別に言語にこだわってもいいだろう？
お前の言っている”俺等”ってお前の仲間は誰だｗ
>>398 >H8 で IBM PC/AT 互換機とか、おかしいと思わんのか？
開発環境か悪い見間違えた、しかしそのC++は例外機構を実装しているのか？
>>400 >ミニコンならなぜ実装されていてもおかしくないんだ？
だから、何故最近の言語に例外機構が実装されているのか
その理由が理解出来れば、実装されていても当たり前だと思えるが。
>>402 >DOS用のAda83コンパイラもあるんだが。
それには例外機構があるのか？
>It requires an 80X86 machine running MS-DOS and a hard disk.
本当に16bit環境"だけ"なのか？ 80386とかは32bitだぞ。
>>403 >つ VM
もしかしてVMと答える奴がいるかなと思っていたが、本当にいるとはｗ
VM自体は何で動いているんだｗ マシン語以外でコンピュータが動くとでもｗ
>>404 >つか、例外がマシン語レベルで対応できないCPUってあるのかｗ
だから、マシン語が例外を処理するのと言語に例外機構を実装出来るのは別だ。
>>407 例外がないとAdaは名乗れないんだよ。ボク。
>だから、マシン語が例外を処理するのと言語に例外機構を実装出来るのは別だ。
ふーん、じゃ別に16bitじゃできないわけじゃないだろw
g++での例外処理はライブラリ関数によって実装されているらしいよ。
0除算はC++の例外ではcatchできない。（WindowsはOSのサポートがあるので知らん）
http://codepad.org/NuLKW17K 誰かがCPU例外が無ければ例外は実装できないって言ってるけど、
CPU例外が無ければcatchできない例外をC++は拾ってない。（Windowsは別）
「CPU例外が無ければ例外を実装できない」はガセ。
その前にCPU例外がないCPUってあるのかｗ
話は全く変わるが、
>>407 が例外を使うケースってどんな場合？
java限定で頼む。
>>408 >例外がないとAdaは名乗れないんだよ。ボク。
だから、それは本当に16bit環境で動いているのか。
>ふーん、じゃ別に16bitじゃできないわけじゃないだろw
だから、マシン語の例外と言語の例外機構の違いが分からないのか？
>>409 http://documentation.renesas.com/jpn/products/tool/j702137_h8s.pdf これを見ると例外処理は制限されているように思うが。
実際に例外処理を書いて動かしたのか？
>>410 本当に16bit版で例外が実装出来るのか知りたいんだが。
>>414 >話は全く変わるが、>> 407が例外を使うケースってどんな場合？
>java限定で頼む。
java自体を使わない。
話を整理するとだな、どのCPUでも例外処理は出来る。
しかし、言語に例外機構を実装出来るのはCPUやOSを限定する。
OSを使わないでプログラム単独で実行されるものは別。
インテルなら8086よりあとのCPU上で動く言語に例外機構を実装されている。
モトローラならMC68000以降。
基本的にはマルチタスクが出来るCPUなら例外機構が実装出来る。
つまり例外とは割り込み処理だ他のタスクに影響を与えないような
保護機能が備わっているCPU上で実装されている。
>>415 ならC++でも何でもいいけど、言語レベルでの例外を使うケースについて説明してくれ。
あと、俺はマジでCPU例外を知らないので、そこはスマン
>>415 基本的な言語レベルでの例外に対する考え方は
>>285 例外として扱うケースは
・リソース不足
・ファイル制御
・外部モジュール制御
こんな感じで、自分のコントロール範囲以外のものをやる。
ゼロ除算なんかは本来はCPU例外だが、判定出来るからエラー処理。
> インテルなら8086よりあとのCPU上で動く言語に例外機構を実装されている。
>インテルなら8086"よりあと"のCPU上で動く言語に例外機構を実装されている。
つまりまとめると、
> インテルなら8086よりあとのCPU上で動く言語に例外機構を実装されている。
割り込みがないCPUってあるのかｗ
なにからナニを保護してるのかさっぱりだな。
つか、例外の実装なんてlongjmpでできるだろ。
>>285 に対して 30 分も経たないうちの
>>286 で FA だってのに、おまえらときたら。
面倒見良すぎだろ。
例外は割り込み処理が備わっているCPU上で実装されているっていうけどさ、
>>427 騙されるなｗ
言語の例外処理機構の実装にCPU例外は関係ない。当然CPU割り込みも関係ない。
ま、結局のところ
あぁなんだやっぱりコストのバカか。
マジでCPU例外と混同してたの？
>>428 いや、わかってるよｗ
ただ、自分で言った言葉が矛盾していることにも
気づいていてないようだから指摘したまで。
なんだかんだ言って親切なマ板は健在だな
ナルホド何にでも例外はあるもんだなw
お前ら本当に馬鹿だな。
はぁ？
俺が思うに、MSやBorlandのC++になぜ１６bit環境で
例外が搭載されていないのは、CPUに割り込み処理がなかったからだな。
>>436 と間違ったことを行って恥を書いた人？
>>438 >例外が搭載されていないのは、CPUに割り込み処理がなかったからだな。
アホか？CPUの仕組みくらい勉強しろｗ
俺が言っているのは言語の例外機構だ。
これだからアホは疲れる。
>>439 お前、落ち着いてレスをよく読んでみろよ。
>>436 > お前らの好きなMSやBorlandのC++になぜ１６bit環境では
ルネサスさんカワイソス
おじいさんが現役だった頃は
どうやって「言語の例外処理機構」とやらが実装されていると思ってたんだろうね。
たぶん、コンパイラがthrow文をゼロ除算命令にするとでも思ってたんだろ。
>他のタスクに影響を与えないような保護機能
どうも例の彼は
そこでググって箇条書きしてくるあたりが例のコストバカに似てるがなｗ
>429であわてて他人のフリをするってコトは、そこまでは自信があったのか？
つかこのパターンは、おじゃばだろ。
>>445 ＞三番目の２返戻値法は例外用の戻り値を用意して持ち回る方法みたい。
＞戻り値派バンザイだなｗ
内部の実装の話だから関係無い
一つの戻り値に混ぜることが重大な欠点だから
お、来たな例外厨ｗ
例外厨ねえ
はりきって「言語の例外機構」をアピールするバカがいないと盛りあがらないな。
459 ：
仕様書無しさん ：2011/02/02(水) 15:20:08
あれ、例外ってC++やPL/SQLなんかもあるけど、ここで言う例外の大半は
JavaかC++だろうな前提は
461 ：
仕様書無しさん ：2011/02/02(水) 16:36:28
>>460 ジャワ 95%
C++ 5%
ぐらいの比率かな、俺の予想だけど
462 ：
仕様書無しさん ：2011/02/02(水) 16:39:22
ジャワでは
catchブロックが複数書けるの知らないんだろうか…
464 ：
仕様書無しさん ：2011/02/02(水) 17:28:36
>>463 ん・
1.まず正常系のコードを必死に書く
2.やっと仕様どうりに動作するようになったので例外、エラー処理に思考を向ける
3.最初のアルゴリズムに影響がでるのが怖いので
>>462 のようになる
ちがうかな。こんな人多いよね
>>464 try句の多重ネストなんて精々2-3重までだろ
catch句の中では例外が発生するような粒度の機能はそうそう使わないし
finally句も例外が発生しそうなのは精々ネットワークリソースのclose失敗ぐらいかなあ
tryの多重ネストの実例作ってみてよ
>>463 複数書けたとしても、特定処理の例外だけキャッチしたいなら
ネストするしかあるまい。
つまらん。「言語の例外機構」みたいなマジなのがねぇとな。
469 ：
仕様書無しさん ：2011/02/02(水) 19:22:04
それとキャッチする例外の粒度が問題だな
470 ：
仕様書無しさん ：2011/02/02(水) 19:25:07
>>450 あれ!!
あの馬鹿、まだ生きているの?
ここでさんざん握りつぶす話が出てるのにいまさらなにが粒度なんだ。
例外の種類でなく、どこでエラーが発生したか知りたい場合は
つトレース
>>472 種類が必要な場合より、どこで発生したかの情報が欲しい場合がほとんどなんだよね。
>>474 ループや条件判断が無い簡単なコードなんだな。
>正しく書く人は少ない
478 ：
仕様書無しさん ：2011/02/02(水) 19:55:09
なんだ、じゃわうんこが沸いてきたな
479 ：
仕様書無しさん ：2011/02/02(水) 19:57:28
>>476 おいおい、ループなんて書くと、エラーをスローして
ループの途中でreturnしちまうんでねえの
480 ：
仕様書無しさん ：2011/02/02(水) 20:03:05
考えてみれば、例外のキャッチって
481 ：
仕様書無しさん ：2011/02/02(水) 20:06:18
それなのに
>>1 ときたら、自分は馬鹿カテゴリにいるのも気づかず
例外を正しくとか・・・・
おい
>>1 お前はエラー処理ができないから例外キャッチワールドに左遷された
ことを自覚せよ
>>476 どこで発生したのかを知るには、
深いネストのtry-catchではなくて、
同じネストレベルに並んだtry-catchだろ。
ループや条件分岐があっても同じ。
ネストする必要なし。
そんなこともわからないカスがプログラマとかやってんじゃねえよ
さっさとマやめて転職しろ。
そのほうがお前にとっても周囲にとっても幸せだ。
>>480 >「馬鹿対応仕様」
そうだよ。利口しかプログラム組めないんならアセンブラでもワイアードロジックでもやってりゃいいじゃん。
まさかCコンパイラは要るとはいわんだろなｗ
>>462 は大げさだが、関数を多重ネストすれば結局同じことが起こる
特にJAVAはそれが顕著。
エントロピーが発散する前に、エラー処理をリファクタリングするべき
485 ：
仕様書無しさん ：2011/02/02(水) 21:07:24
でましたね、リファクタリング地獄
486 ：
仕様書無しさん ：2011/02/02(水) 21:08:37
リファクタリングという名目下で発生するデグレード地獄の多重ネスト地獄
戻り値こそネストだろ、という奴は…でてこれんわなｗ
>>470 この板の人間ならアレ？ということを
えらそうに知ったかをこいて突っ込まれたあげく
意地になって全レスかましたうえに敗走する芸風は
なかなか他の奴には難しいと思うんだがｗ
戻り値厨が頑張って釣ろうと
例外がどこで起きたかって話で思い出したけど、
>>485 > 一度動作したソースはごちゃごちゃいじならいが鉄則なのですが・・・
リファクタリングというのは、動作したソースをいじるのではなく
ソースをいじるときにやるんだよ。
プログラムの改修などでソースをいじる時があれば、
どうせいじる訳だから、いじる箇所をリファクタリングするの。
はい、リファクタリングとテストは不可分である云々の議論禁止。
例外が起きたら、何をすればいいかわかってない人がいる。
いや、重要だろ。
ファイル読み込み終了で
>>495 EOF まで読むと例外投げる言語も結構あるんだけど…
java.io.EOFException
java.io.EOFException
思うに例外って後続処理飛ばすから、
> 思うに例外って後続処理飛ばすから、
＞逆、後続処理飛ばすべき自体が起きたから
502 ：
仕様書無しさん ：2011/02/03(木) 09:07:17
EOFの例外ってほんとうにダサイ仕様だよなあ
つかEOFってエラーじゃないだろうに。
504 ：
仕様書無しさん ：2011/02/03(木) 09:11:02
>>503 そう、それを例外に棚上げするジャワを設計した人がﾀﾞｻｲ
506 ：
仕様書無しさん ：2011/02/03(木) 09:12:42
終了のシグナルならば SIG_EOFとかのシグナルだせばいいじゃんか
>>501 「～する」という仕様の関数がそれをできないとき、関数が単に return して
実行が継続するようなことは常に危険だと断定できる。
利用者は必要に応じて「TRYで括って戻り値に変換するような事」を
選択することもできる。
何もしなければ意図された動作ができていないという判断に基づいて
処理が中断されていくのが自然。「強いられる」などということは無い。
508 ：
仕様書無しさん ：2011/02/03(木) 09:15:29
さらに言うならば
それにしてもファイルポインタが外れたのをEOFExceptionとネーミングするのは
510 ：
仕様書無しさん ：2011/02/03(木) 09:18:10
で、こんな基本的な糞仕様に縛られる
>>1 は? コメントを求める
>>508 ファイル終端に達した途端に常に EOFException が発生するとでも思ってるの？
そうならもう一度
>>498
たとえばInputSteam.read()は正常のEOF時は-1を返すからcatchには行かないけど、
513 ：
仕様書無しさん ：2011/02/03(木) 09:26:23
>>511 ファイル処理は
読んでいる途中で発生するエラーってほとんどないだろう
大体は、パスが不正でオープンできないとか
パーミッションが不正でアクセスできないとの読み出す手前で発生するエラー
が大半だろう
514 ：
仕様書無しさん ：2011/02/03(木) 09:30:29
読んでいる途中でエラーが発生するケースは
あれ、read()って一回-1が来た後もっかい呼ぶとEOFException出るんだっけ？
メイン関数やメインルーチンで例外受けているようなところだと
517 ：
仕様書無しさん ：2011/02/03(木) 09:57:07
ジャワ糞はファイル処理もろくにやったことがないのがばればれだな
>>514-515 で、仮にそうだったとして、何が言いたいの？
まさかそんな経験則を元にしてその他のエラー処理を省くとか？
519 ：
518 ：2011/02/03(木) 10:05:45
520 ：
仕様書無しさん ：2011/02/03(木) 10:36:48
>>518 ええっっっっっっ
エラー処理を無視するやつってジャワ糞しかいないよ
じゃぁ何が言いたかったの？単に自分の経験を披露したかっただけなの？
522 ：
仕様書無しさん ：2011/02/03(木) 10:39:42
>>521 いまあるがままの言語仕様とそのくせをきちんと見抜き、適切な
アルゴリズムを実装するのは
>>521 の仕事だよ。自分であらゆるレアケースに
対応できるエラー処理を考えてみてはどうかな
523 ：
仕様書無しさん ：2011/02/03(木) 10:43:17
出来る人 どんなささいなことでも前向きに自分の問題と照らし合わせて
前進できる人
出来ない人 なにがいいたいの?とか言い返すだけの
>>521 な人
ひとりごとだったらしいな。気にしないでいいよ。
525 ：
おじゃばさま ：2011/02/03(木) 11:56:55
どうやら俺の出番のようだな
>>501 ＞例外をスローする関数はシステム全体の事をしらないだろう？
誰もシステム全体の話なんかしてないよ
関数内の話
関数は全体どころか親関数でさえ意識してはいけない
だから、関数から例外をスローしたらそのあとのことは考えない
だれがキャッチするとかはスローした関数からはどうでもいいことなんだよね
>>526 こういうマに限って、MyFuncExceptionとかスローする関数を作る
その後どうすりゃいいのかさっぱり分からない
これだからJAVA上がりのマは厄介だ！
528 ：
おじゃばさま ：2011/02/03(木) 15:10:14
>>527 まあそういうなよ。俺みたいにジャワのえきすぱあともいるんだから。
>>527 わからないのはお前が馬鹿だから
マ辞めろ
530 ：
仕様書無しさん ：2011/02/03(木) 16:27:05
出来る人 たとえ関数内部のささいな仕事でも、全体に及ぼす影響までイメージできる人
出来ない人
>>529 な人
MyFuncExceptionとがゴミだろ。
このヒトたちCができるようにも思えないのはなぜなんだろ…
汎用ライブラリの関数を書いている時点で、
534 ：
仕様書無しさん ：2011/02/03(木) 17:37:04
ぶっちゃけExceptionなんて全部スローしちまえば関係なし
正しい種類のExceptionを投げるのが大事なのであって、
＞スレタイ
使い方が正しいのかどうかってどうやって判断/試験/確認すればいいの？
538 ：
仕様書無しさん ：2011/02/03(木) 22:33:51
>>535 例外を投げのはおまえじゃねえーだろうw
それともUNIXのシグナルのように積極的にSIGを飛ばすのか?ジャワでw
539 ：
仕様書無しさん ：2011/02/03(木) 22:34:33
またジャワ糞がわけの分からんこと言い出しましたね
540 ：
仕様書無しさん ：2011/02/03(木) 22:53:37
java.sql ResultSet内の
自分自身が例外としてスローされる
>>540 SQLStateとかErrorCodeでわかるだろ。
>>538 >
>>535 例外を投げのはおまえじゃねえーだろうw
> それともUNIXのシグナルのように積極的にSIGを飛ばすのか?ジャワでw
飛ばすのはSIGじゃなくて、Exceptionだよ。
このふたつは違うものだよ。
>>535 そうなんだよね。
たとえばこんな関数があったとき
void foo() {
try {
bar();
} catch (Exception e) {
throw new MyException(e);
}
}
関数ってのは自分の役割を果たせばいいだけなんで、
fooを中心に見た場合、送出したMyExceptionを誰がキャッチするかなんて、*意識してはいけない*し、
barから発生した例外をbarの中の実装コードのどこで発生したかも*意識してはいけない*
ところでおまいら、DbC（契約による設計）ってやってる？
あれだろ？ 契約書貰ってから設計しろってやつ
>>544 みたいな自分勝手で破壊的な例外処理さえ禁止できればなぁ
この際、
Exceptionクラスに後処理関数デリゲートでも持たせてみるか？
うまくいかなかった時の戻り値を最初に決めて、例外が起きずに最後まで
言語の例外機構って結局なんのつもりだったんだろ…
>>547 そういうのはExceptionのかわりにContinuationでやれ。
>>545 できる範囲でやってる。
とはいえ、やはりEiffelみたいに言語仕様がDbCを意識してないと
効果が薄いよね。
例外の型とかイベント駆動のやつのイベントの型とか
難読化がはやりだからしょうがないんじゃないの
例外の仕組みを理解できてないから、
そういや、よくあるマイナス値を異常を示すフラグといえば、
人が増えれば難易度も上がるでしょ。やる人がピン、キリだから
つか、例外禁止されちまったから、
例外の使い方をろくに知らない人の共通点
まずは正しい例外の使い方を定義してくれ。
俺定義を押し付けられても困るけどな
呼ばれる側と呼ぶ側の連携が取れてないと、何やってもダメでしょ
562 ：
439 ：2011/02/04(金) 23:23:13
Javaでぬるぽをcatchするのはいろんな意味で負けだと思う
っていうか、手を入れれない場所の潜在バグの暫定対応以外で
例外って、そもそも期待されている結果を返すための処理を完遂できなかった場合に、
>>565 別にそーじゃないようにも組めるし
長文の意味まったくないね！ね！
>>564 バグだから捕まえる必要はない（直せばいいから）というのは間違いではない。
だけど徹底的にテストしたところで、バグをなくすことは不可能という意見に賛成なら、
バグを検出するため（ログを取るなど）に捕まえる必要があるというのも理解できると思う。
またバグがあっても一部の機能が使えないだけに影響を抑える理由も理解できると思う。
この二つを満たそうとするなら、どんなコードでも例外が発生する
可能性があると仮定したコードを書くべきだし、
どの関数でも終了処理を必ずやってからリターンなり例外発生なり
してから終わるように作らないといけない。
すべての関数でもれなく正しいエラー判定を行って、正しいエラーフローを書かないといけない。
これをやった場合、戻り値だとすごく大変になるというのはわかると思う。
だけど、例外だと楽に書けるよ。
ところで、例外とエラー処理を一緒くたに語るのはある意味で間違ってるよね。
>>568 実際のところ、そういうコードを書くのはまれなんだけどね。
処理Aの例外処理と、処理Bの例外処理が違うってことはあまり無い。
ほとんどの関数ではこのパターン。
try
{
リソース確保
処理A();
処理B();
処理C();
}
finally
{
リソース解放
}
解放すべきリソースがないなら（ローカル変数だけ使っているとか）
tryそのものが必要なくなる。
で、最終的に例外は処理復帰可能なチェックポイントでキャッチされ
エラーをログに出してから処理を復帰する。（場合によっては終了する）
エラーをログに出すだけだから、なんの例外かを知る必要はない。
例外の種類なんて処理を復帰させるか終了させるかの判断に使う程度。
というか、例外の種類が発生元で違うのを一緒くたにcatchとかアホやらず
>>570 実際やってみれ分かるけど、
サンプルコードのような全体が小さいアプリ以外は
catchで例外種類ごとに処理することなんて無いよ。
デフォルトで関数を中断して親にエラーが起きたことを通知するので、
これ以外のことが必要な場合、つまり例外が起きても
関数を中断したくないという時にしかcatchは書く必要はない。
それはマイナーケース。
catchじゃなくてfinallyはリソース解放で使うけど、関数で使った
すべてのリソースを解放するだけなので
なんの種類の例外かなんて調べる必要がない。
ま、C++の場合はfinallyがないから catchで代用するしか無いけどね。
>>570 そうそう。そゆこと。
んで普段から例外持ってるメソッドコールしてるって意識がないから、
try書くクセとかもなくて、チェックかけずにParthしてこけたりとかよくやってたりする。
なんというか例外を特別視しすぎなんだよね。
あとは冗長メソッドを使いすぎたりする人も似たような事よくやらかしてるイメージ。
一本道で一番期待してる結果になる条件で動かす場合って、
そういう脇道にそれる系のコードには到達しないから、
単純に意識がむいてないんじゃないかなーと、思ってる。(´･ω･`)
例外ならtry書かなければ関数を中断してくれるから
もみ消さなくてももみ消せるから便利！
>>562 > 一般的な構造化例外じゃなくC++特有の例外だったんだな。
「構造化例外」は Windows 固有のもの。どちらかというと
C++ 例外のほうがまだ一般的。
> つまり、C++の例外も規格的には準拠した仕様だと認められているようだ。
意味不明。 C++ の例外は C++ の規格で規定されているもの。
準拠するも認めるもクソもない。
> この程度も例外として処理出来ない「C++の例外」と言うのは．．．
VC++ なら構造化例外用拡張構文を使うなり _set_se_translator を
使うなりすればいい。
例外、つかエラー処理と後始末は別の話だから
usingはいいよな
そういや前に4k行メソッドで例外が発生したことがあった。
どーすりゃいいのって
4kのメソッドを分解する。
try句を適切に設定しろ
というかメソッドを分解しろｗ
例外の型とやらを細分化するってことは、オマエは起こりうる全ての
>>583 マトモな設計がしてあれば、
モジュール毎にどのような例外が必要なのかは洗い出せるだろ。
実装時に必要になった例外については、個別に対処すればいい。
自分が投げる例外にマッチした例外クラスがあるかを探す。
なければ、どの例外クラスからサブクラスすればいいかを考える。
できないなら転職しろ。
>>583 すべての例外はExceptionクラスのサブクラスだから、
Exception用のコードを書けばいいんだよ。
それ以外の処理をしたい時だけ、特定の例外の型用の
コードを追加すればいいが、そういうことはあまりない。
>>584 >マトモな設計がしてあれば、
>モジュール毎にどのような例外が必要なのかは洗い出せるだろ。
想定外の事が例外として現れるんだろがハゲ
>>585 それがダメって言ってんじゃないの？ 一部の バ カ は。
>>586 え？
投げられてもいない例外が飛んでくるってこと？
定義されてもいない例外が飛んでくるってこと？
そりゃ怖いなw
マジレスすると、
自分が書いているコードに意味がないような種類の例外は
全部スルーしてしまえばいい。
その例外に意味があるような部分を担当している奴が
対処すればいいんだよ。
マジレスすると
＿＿＿_ ） 『 例外処理の中で例外出したらどうなるの？』っと、
でもjavaだとcatchしないとなんか文句いわれた思い出あるんだけど
591 ：
仕様書無しさん ：2011/02/05(土) 11:33:11
あほな
>>565 の言うマジックナンバーってあるときは必要
tcpコネクションのメソッド内で発生したエラーが
「例外が発生しました」じゃわかんねーつうの
ipアドレスが不正
アクセス先がリスンされてないサーバだった
ユーザ名が不正
パスワード不適合などひとつのメソッドでエラーの原因因子も多数ある場合は
どうするのかおしえてくれよ
592 ：
仕様書無しさん ：2011/02/05(土) 11:34:46
Socket
593 ：
仕様書無しさん ：2011/02/05(土) 11:39:48
java.lang
594 ：
仕様書無しさん ：2011/02/05(土) 11:41:37
それと-1 -2とかがマジックナンバーとかいってるが数値リテラルで書きっぱなし
>>591 > あほな
>>565 の言うマジックナンバーってあるときは必要
おい、理由はどうした？ｗ
> tcpコネクションのメソッド内で発生したエラーが
> 「例外が発生しました」じゃわかんねーつうの
お前例外知らないだろ？例外というのは、ちゃんと
例外の細かい理由まで教えてくれるんだが。
お前が言うのは、戻り値の場合によく見られる話だよ。
負の数値が返ってきたらエラー。
-1は○○、-2は△△、-3は□□。
ヘルプには数値ごとに理由を書いてあるが、
めんどくさくなって0未満なら全部
if(foo() < 0) {
printf("エラーが発生しました");
exit(1);
}
とか書いてあるのをよく見かける。
>>593 お前CPUの例外と勘違いしてるだろ？
例外が発生したら、SecurityManagerのメソッドが
非同期で呼び出されるわけじゃないぞ。
CPU例外だったら、今実行している関数とは無関係に
例外ハンドラが非同期で呼び出されるが、今話している例外ってのは、
関数の戻り値と同じだ。もちろん非同期ではない。
TCPコネクションを接続するconnectというメソッドがあったとしたら、
例外でエラーを戻すということの意味は、
接続エラーの時の戻り値が大変便利になったというだけの話だ。
>>591 多分、そういう情報をメンバに持つ派生クラスを作れって言われるだろうなｗ
まだCPU例外と勘違いしてるのか
>>597 この場合は例外の型を分けるべきだろ。
ネットワーク関係のライブラリの接続エラーと
ユーザー認証系のライブラリの認証エラーでは
例外の種類は違って当然
戻り値と同じことを考えるからだめなんだよ。
戻り値だと、int型などのまとめることしかできないからな。
ネットワーク系のライブラリが接続できないときに-1を返す
ユーザー認証系のライブラリでも接続できないときに-1を返す
一つの関数内で、ネットワーク系ライブラリとユーザー認証系ライブラリを
両方を使うとエラーが両方共-1だから区別がつかない。
だからエラー番号を置き換えないといけない。戻り値だと大変だね。
だけど、その大変さは例外には当てはまらないから、簡単に違う型の例外を発生できる。
戻り値が大変だからって、例外も同じことをしないといけないということではない。
>>594 C言語のenumは結局のところint型だから
# ↓擬似言語
enum ERROR{ ERROR_1, ERROR_2, ERROR_3}
enum ERROR e = foo()
print e;
などとやっても、結局数値しか表示されないんだよね。
だからデバッグ中にエラーコードを表示しても数値しかわからないから、
この数値はどんなときに発生するエラーなんだ！ってなる。
eをprintしたとき、 ERROR_1 という文字列が表示されて欲しいんだがね。
Javaとかではできることだけど。
Cのenumは最終的には使えん。
無駄な努力をすることが美徳と思ってる
603 ：
仕様書無しさん ：2011/02/05(土) 13:34:35
-1 -2はenum値に対応したperrorのようなヘルプストリングメソッドを作れば解決するだろう
作らないといけないだろ。
605 ：
仕様書無しさん ：2011/02/05(土) 13:38:09
単純なことをなんでここまでまわりくどくできるか
606 ：
仕様書無しさん ：2011/02/05(土) 13:41:50
public Socketの糞仕様もオーバロードの悪しき使い方の典型だな
perrorのようなものが必要になるってことは
608 ：
仕様書無しさん ：2011/02/05(土) 13:43:32
>>606 ようするに、UNIXのすべてのものは
ファイルであるという考えを否定しているのかい？
>>608 はぁ？
お前が馬鹿だからちゃんとした使い方が
わからなくて困ってるだけど。
何が困るのかちゃんと説明してみ
611 ：
仕様書無しさん ：2011/02/05(土) 13:47:10
え・public Socketはジャワのクラスだすよ
>>606 発生する例外は抽象化しているので
180度違ったとしてもそれはハードウェアの
話であって関係ない。
例外とCPU例外をごっちゃにしているやつは。
例外ごとに、違う処理をするんだ！
なんて思うだろうけどｗ
例外は戻り値の数値がもっと便利になって
614 ：
仕様書無しさん ：2011/02/05(土) 13:51:35
それはステータスコードであって
616 ：
仕様書無しさん ：2011/02/05(土) 13:55:19
>>615 だから -1 -2 でもリテラルで書けばマジックナンバーだろう
お前俺の言っている事が全く理解できてないのかよ
仕様書に明記してenum化する、またはdefineする
そうすりゃあステータスと同等だろう
617 ：
仕様書無しさん ：2011/02/05(土) 13:56:25
単純なことをまわりくどくはできても
内部で使われてるだけのマイナーな数値だから
619 ：
仕様書無しさん ：2011/02/05(土) 13:58:00
リターン値は呼び出し元にもどるだろう、内部で使うだけなら
620 ：
仕様書無しさん ：2011/02/05(土) 14:01:18
お前が作るメソッド内部に限定しているから
HTTPのステータスコードは404とか有名なものは
SocketExceptionという例外が発生しましたといえば、
ソケット関係だってわけるけど、
-1という戻り値が発生しましたじゃ、
なんのエラーかすらわからないな。
>>600 のいうように、
数値から定数名を取得できないし。
623 ：
仕様書無しさん ：2011/02/05(土) 14:05:21
>HTTPのステータスコードは404とか有名なものは
お前が作ったエラーコードが
625 ：
仕様書無しさん ：2011/02/05(土) 14:08:11
>>624 お前救いようのない馬鹿だな
有名になれなきゃステータスの設計はできないのかよ
あーそうですか はいはい ジャワ糞
＞＞623 HTTPであっても数値ではなく、
定数ちゃんと使えよ能なし野郎
http://struts.wasureppoi.com/servlet/09_status_kind.html 302 SC_MOVED_TEMPORARILY リソースが一時的に他の場所に移動したこと、また将来の参照の際にはこのリソースにアクセスする元々の URI を依然として用いるべき
303 SC_SEE_OTHER リクエストに対するレスポンスを異なるURIから発見することができる
304 SC_NOT_MODIFIED リソースが利用可能で変更されていない
305 SC_USE_PROXY リクエストされたリソースへはLocationフィールドで指定されたプロキシを通してアクセスしなくてはいけない
307 SC_TEMPORARY_REDIRECT リクエストされたリソースが一時的に異なるURIに存在する
400 SC_BAD_REQUEST クライアントから送られたリクエストが文法的に間違っている
401 SC_UNAUTHORIZED リクエストがHTTP認証を要求する
402 SC_PAYMENT_REQUIRED 将来利用するために予約されている
403 SC_FORBIDDEN サーバがリクエストを理解したがリクエストを完了することを拒絶した
404 SC_NOT_FOUND リクエストされたリソースが利用可能でない
627 ：
仕様書無しさん ：2011/02/05(土) 14:10:46
>>626 お前w 日本語理解不能なんだな
俺はは最初からenum化、追加してdefine化をきちんと伝えているし
設計書とのリンクも明記し続けているよw
629 ：
仕様書無しさん ：2011/02/05(土) 14:15:49
ジャワ糞が逆ぎれしたようです
戻り値の問題はある（自作の）関数が、404を返したとして、
どうでもいいけどjavaをジャワ()なんて書くのは全角数字を使う並に違和感あるな
ところで、なんでこのスレこんなに伸びてんの？ 過疎板のくせに生意気だぞ。
vを発音できない世代の奴なんでしょ
＿＿＿_ ） 『戻り値の範囲が-5以上の数値だったらどうするの？』っと、
大部分の言語で採用されている例外。よく使われている言語で
ぶっちゃけ戻り値で、期待してる値とは別の意味がある識別子が返ってくるなんて仕様があった場合、
例外が発生したときにやる処理は
別に仕様書か関数ヘッダにでも、正しい情報さえあれば、
> 仕様が書かれてないなら返値の方がいい。
最近ちょっとjava触ってて、検査例外はそこそこ便利かなーって感じることもあったんだけど
あー、これは検査例外の問題で正しく使えないのとは別だったわスマンコ
>>639 答える必要はない。
戻り値見なければいいんだからな。
それがC関数の基本だ。
どうしても戻り値を処理して欲しい時だけ、
関数作った人が解説するだろうからな。
643 ：
仕様書無しさん ：2011/02/05(土) 15:11:18
>>635 ちがうってばさw
Cはアセンブラに毛が生えた低水準の言語。アセンブラほど無敵でなんでも
できるわけではないけど、ほぼアセンブラに近い実装が高級言語イメージで
できる。しかしエラー処理やらなんやらぜんぶ神経つかって作る必要がある。
蛆虫のように低レベルマが激増した時代にアドレスエラーとかエラーチェックを
正確にしないマが激増した。頭の良い開発者は
馬鹿用にOO仕様を作ろうと発起した。そしてジャワとエラー処理を簡略化できる例外
が実装された だよ
検査例外はあったら便利に使えるのかもしれないけど、
645 ：
仕様書無しさん ：2011/02/05(土) 15:15:07
TCPソケットの例を出した俺が意地悪いのだと思うけど
>>642 > 戻り値見なければいいんだからな。
> それがC関数の基本だ。
うん知ってる。C言語ではよく
エラー処理をしてないコードが多い。
サンプルです。エラー処理してません。
そういうコードをコピペして使うのが
C言語・・・というかお前の基本。
>>643 ようするに、エラー処理で無駄な努力をしている俺は
頭がいいと考えているわけねｗ
>>645 > 戻り値見なければいいんだからな。
> それがC関数の基本だ。
ということなので、
Ｃ言語では
「入力エラーが発生しました」
すら表示されないで落ちるぞ。
649 ：
仕様書無しさん ：2011/02/05(土) 15:20:32
>>647 馬鹿のための箱庭仕様の中でいくらがんばっても所詮箱庭盆栽の狭い世界限定
>>648 のような馬鹿が増えたため、C++/Javaなどが作られた
>>649 まさにこれだなｗ
> C言語を使っている人は古株が多い。自分の力に自信を持っている。
>
> 例外は多くの言語で採用されていることからも
> 戻り値でエラーを返すよりも、優れた機能であることは明白。
>
> どんなにC言語で自信を持っていたとしても、そいつよりも優れた言語開発者が
> 戻り値エラーが使いにくいという反省から生み出した例外を否定することは無理。
>
> 自信を持っているやつが、理解出来ない例外をを
> 優れていると認められずに頑固に貼りつくからスレが伸びる
ぶっちゃけ馬鹿のためっていうか、こまけーこと気にしないで
>>639 少なくとも呼び出し先の関数を読めば返り得る値は分かる、
って程度のもんだ。
値の意味まで分かるかどうかはその他のコードの
書かれ方によるし、何とも言えない。
関数名だけでも分かりやすく付けてあれば、
かなり把握できると思うよ。
程度の話で、仕様書が無い時点で泣きたくなるけど、
実際問題弊社じゃ泣いてる奴ばっかりだぜ。
論外だ、と言えない現実が辛いわ。
653 ：
仕様書無しさん ：2011/02/05(土) 16:03:49
俺の知っている院生はすげえセンスの良いUNIX C使いだけどなあ
>>640 >次バージョンで例外Cもスローするように変更されてしまうと、そのメソッドの呼び出し元では
>例外Cはハンドリングされていないことになる
結局、元の例外クラスが持ってないインターフェイスは実装しちゃマズイんでしょ。
で、元の例外クラスって、それ以上拡張する必要がないほど完璧なの？
ってことになる様な・・・
大した事出来ねーんなら、細分化しなくてもいいじゃん。
それに、関係ない例外が自分の所までたらい回しで上がって来るって、
いかがなものかと。
そういう作り方って、推奨されてるものなの？
例えば、プロセスの初期処理でINIファイルを読むとする。
>>655 Java の検査例外ですね。わかります。
658 ：
仕様書無しさん ：2011/02/05(土) 16:35:47
そこでiniファイルが消失した場合は
659 ：
仕様書無しさん ：2011/02/05(土) 16:37:17
必ず存在する保証なんてないよなあ
Javaがはやったのは当時金のなる木だったからだろ
try要らないって言われても、誰かに文句言われることない？（ソースの品質管理の人などに）
>>661 「必ず存在する」が前提としてあるなら問題ないだろ。
前提に出来ないなら戻り値を使う場合のコードもダメだし。
> 念の為にtryで括って握り潰すコード入れたくなるだろ？
お前はそうかもしれんが他のまともに例外を使うプログラマはそうではない。
>>661 > try要らないって言われても、誰かに文句言われることない？（ソースの品質管理の人などに）
お前みたいな無知な奴に文句言われるんだろうなｗ
うぜぇ
「必ず存在する」というのはもちろんシステム条件だ。
必ずあるものが無いなら、無い旨通知する必要があるのではないかと。
客「あれ？○○ってファイルが無いと動かないよ」
このあたり、認識の違いだよなぁ
いやいやｗ
>>661 > 上位も下位も何やってるか分からんから、
> 念の為にtryで括って握り潰すコード入れたくなるだろ？
仕様というか責任範囲を明確にする努力をしろよ。
馬鹿か？
>>666 そんなんばっかやってると、次の仕事が来なくなる諸刃の剣だけどな
そうならないために、作る側が作る時点で
「こういうことが想定されるけど仕様にないです。どうするべきか追加してください。
また、エラーとする場合はどのような動作にしますか？エラーメッセージはどうしますか？」
みたいな仕様確認をしておくでしょ
仕様書に書いてなかったからやりませんでした。
が通用するレベルの程度の低い仕事ばっかなら楽でいいんだけどねｗ
671 ：
仕様書無しさん ：2011/02/05(土) 17:12:10
672 ：
仕様書無しさん ：2011/02/05(土) 17:14:29
デジタルデータを「絶対存在する前提」でコードを書くなんて
よくできたプログラマーはそういう言語仕様の違いで例外に文句いったりしない
＞仕様というか責任範囲を明確にする努力をしろよ。
googleさんもそうだけど、理想通りの環境でないと例外は通用しない。
googleさんもそうだけど、理想通りの環境でないと戻り値でのエラー通知は通用しない。
>>672 のレビュー結果
-誰に対してレスをしているのかを明確にしてください。
-スレの趣旨にそぐわない内容は削除してください。
-「ジャワ」は一般的ではないため、用語解説をつけるか、もう少し一般的な単語に置き変えてください。
googleがそうだから俺もそうするって、馬鹿みたいなこと言うのはやめようなｗ
「戻り値無視」は伝統技法だろｗ
賢いフリしてあげ足取りしかしない口先だけのカスって、どこの業界でも組織のガンだよなｗ
>>674 後々使いまわされ、処理に携わる人間がすぐ気づけるようにソース中にコメントとして記載
ソース見ない層からも確認できるように仕様書に明記したり、会議で出し議事録として残したり
問題管理などで明確な確認を取り付けて、現状そういう仕様となっていることまできっちり残すのが
仕様を明確にする努力でしょ
こうだからこうだって、そこで思考停止してしまうのは、所詮中華や底辺プログラマだよな。
組織の癌といえば、指摘を揚げ足取りされたつって火病る老害とかも困りものだわｗ
>>681 うんじゃ、UNIXのソース見てくるか？
世界中で動いているサーバのソースを。
685 ：
仕様書無しさん ：2011/02/05(土) 17:46:46
はいはい、いつものパターンになってきました
ジャワでぐぐったらジャワ島かカレーばっかだったわｗ
正しく使えないんじゃなくて、そんな事に細かくこだわらなくても、そこそこ
そういう人は頭いいから、例外がどうのこうのでめんどくさいって思っていても
689 ：
仕様書無しさん ：2011/02/05(土) 17:52:09
あららら、例外を語る前に そもそも仕様すら明確にできない問題点が
690 ：
仕様書無しさん ：2011/02/05(土) 17:53:57
>>686 お前、ぐぐるなよw かわいいやつだなあ
日本人が作るソースは再利用性が非常に低い。
692 ：
仕様書無しさん ：2011/02/05(土) 17:58:13
>>691 はあ? ﾎﾟｶｰﾝ
>戻り値がintならコピペで使える。
お前内部の動作仕様も理解しないで、とりあえず使えるから
コピぺしておきますねって終了させるのか
>>674 システム全体を統括する責任者（アーキテクト）は居ないの？
システム全体を統括する仕組みが実在しない国際社会を
例に喩えて満足ですかい？
>>692 ・信頼性
１０年動いているコードのコピペ ＞＞＞＞ お前が自力で時間掛けて作ったコード
おまえさんは悪い日本人思考の典型。
695 ：
仕様書無しさん ：2011/02/05(土) 18:01:30
なあんか、戻り値=悪 みたいな感じだよねえ
696 ：
仕様書無しさん ：2011/02/05(土) 18:03:52
>>694 その信頼性の高い10年動いているコードを超えるものを作ろうとする
気概はないのですかねえ お前さんこそ ゆとり世代のぽかーんな日本人だろ
少なくともGoogleは既存のオープンソースをコピペすることを選んだってわけだ。
698 ：
仕様書無しさん ：2011/02/05(土) 18:12:12
javaで例外をきちんと正しく使うためのルール
699 ：
仕様書無しさん ：2011/02/05(土) 18:13:14
あれれ間違えたw 3. rm -rf /ね ためしてみてねJavaエキスパートさんたち
>>691 へー初耳だ。
欧米で作られたプロプライエタリなソフトのソースを
見たことがあって言ってるんだよね？当然。
ライブラリや他人が用意してくれた便利なのものは
>>691 これは酷い
海外だろうが国内だろうがまともなマが見たら怒っていいレベル
どうしても主張が正しいって言いたいなら要出展
なんかスレ趣旨とは直接関係ない言語批判に持ち込む馬鹿が多いから、
もっと特徴的な部分があるから、そこでNGにつっ今度きゃイイヨ
絶対に発生しないと事前にチェックかけてたり、仕様で明記していても
例外のアレやコレやを色々使って色々できることは分かったけど、じゃあそれ
>>694 > ・信頼性
> １０年動いているコードのコピペ ＞＞＞＞ お前が自力で時間掛けて作ったコード
おいおい
１０年動いているコード「のコピペ」
だぞ？大丈夫？
そもそも、「他がやってるから自分もそういうスタイルのコーディングする()笑」
>>707 自分やチーム内のほかが迷惑する可能性が上がる
一般的な仕組みなの自分だけその程度も理解出来てないような状況だと仕事にならない
まぁ現実は、1人くらい馬鹿が紛れ込むのは避けられないからそうそう質は上がらんけどな
で、周りに合わせて無駄を無駄としてやるしかなくなる
例外よりもイベント駆動のプログラムを理解できてない奴がいやだ
あっちは正常系にゴリゴリ絡んでくるから、
例外すら理解できてない馬鹿が紛れ込むとどんどん糞コードが量産されていく
まじ泥沼
各プログラム言語で
イベント駆動型ってのも、例外と似た様な性質を持つよな。
CPUというのはハードウェア
714 ：
仕様書無しさん ：2011/02/05(土) 18:59:45
あらら、ぐでぐでになってきちまった
>>712 問題はそういう仕組みじゃねーけどな
理解できない馬鹿が混在する環境が問題なんだよ
>イベント駆動のプログラムを理解できてない奴がいやだ
>>716 それがいるんだよ。
どこがmain関数なんだ？って
そこばっかり気にしてるやつ。
>>712 イベント駆動がCPUの基本から外れるとか、おいおい、おまえどういう教育受けてきた？
CPUのモデルはオートマトンだ。
そしてそのオートマトンはイベント駆動状態遷移機械なのだが？
CPUの基本であるオートマトンに忠実に従えば、
自然とイベント駆動なアーキテクチャにならざるを得ない。
例外難しい
じゃJavaなんかやめてPHPなりPythonやらRubyにすればもっといいわな。
ずいぶん乱暴な。
>>718 CPUの基本は上から処理が流れるのを基本として
ループや比較やジャンプがあるだけだよ。
いきなり何か処理が始まるとかありえない。
>>722 0x100番地からブートするんですよねｗ
割り込みとか知らないんですかそうですか。 割り込みハンドラに色々登録して、
>>724 そうかもしれんが、今のフレームワークとINT２１は違う仕組みだろ？
そこが問題ではなく、誰がフレームワークを希望したんだと。
そして、いい結果がでたのか？と。
そういう風にしか見れない人だと例外にしてもイベントにしても、
面接でさ、お客さん怒らせたくないから、
>>726 俺のことかもな。
Windowsの時もそうだったが、
メッセージ駆動がよく分からなかったので
Windowsのソース見せろと思った。
デバッグ版のWindowsを探したが結局見つからなかった。
>>725 今の時代はフレームワークを普通に使う時代なんだが
お前は20年ぐらいこの世界から遅れてるだろ。
自分の狭い仕事の中でしか生きてないな。
10年ぐらい前からお前の周りは何も変わってないだろ？
そんなこと言ってる奴でもじゃハードがどうこう、ってと弱腰になるのがおかしいんだけどね。
731 ：
sage ：2011/02/05(土) 19:52:50
やっぱ日本人も火病起こすよな。ﾁｮﾝ固有の気質じゃないよな。
>>727 戻り値は要求したものだし、例外は要求を実現する過程で
どうやっても完遂できないイレギュラーが起きたことを示すもの
何に使うかが問題
ジエンご苦労様です
>>727 > 「例外と戻り値どちらが優れていると思いますか？」
> って聞かれたらどうすればいい？
適材適所。C言語とC++のどちらが優れているのかと同じ質問。
C言語を使うなら標準のやり方である戻り値を使うしか無いし、
C++を使うなら標準のやり方の例外を使うしか無い。
もちろんJavaやRubyやC#も例外が標準なのでそれに従う。
標準のやり方こそがあるべき姿で、それに反するのは
よっぽどの理由があるときだけ。
そう言っておけばいい。
まあ、C++はCよりも優れたものとして
例外をまともに使えない人種は2種類いる
いや、32bitでないと言語の例外機構はできないそうだから意味はあるかも。
そもそも例外が使えない環境で例外で処理しろなんて話ではなくね
例外と32bitが関係していたのか。初耳だな。
>>740 さぁ？言語の例外機構ｗがなんのことかわからんからさっぱり。
>>739 そうそう。
C言語ではそもそも例外は使えないのだからお呼びじゃない。
なのに、CPU例外と勘違いしてしゃしゃり出てくる。
このスレは例外は戻り値エラーなんかよりも優れたものであるという
前提のもと、C++やJavaで例外を戻り値に落として使うような、
「例外を使えないプログラマ」を馬鹿にするスレ。
使用する言語の縛りしかり環境しかり、仕様上例外を扱えないのはそもそもどうでもいいだろ
で、言語の例外機構ってなによｗ
>>727 相手がINT21なおじさんなら、戻り値と答える
相手がWindowProcな先輩なら、どちらも利点があると答える
相手がフレームワークおんりーな人なら、例外以外ありえないと答える
ま、今の時代例外を使うのが普通だな。
>>739 >例外が使えない環境
じゃそれはどんな環境だよ？8086”以前の”CPUかｗ
>>742 そっから発展して、うまいこと馬鹿を教育する術なんかが出てくると優位性も生まれるんだろうけど
スレ趣旨すら勘違いして言語批判なりし出す馬鹿が必ずしゃしゃり出てくるんだよなｗ
例外はJavaの仕組みだとでも勘違いしてんじゃねって感じのJavaアンチが沸いてるあたりとか、
なんかもう痛々しくてなんともいえない切ない気分になったわ…
>>749 CPUに例外が何の関係があるんだよｗ
まあ、8086のような今のCPUの何万分の1の
速度という極端に遅いCPUでは
遅すぎて使えないだろうが。
>>749 ()笑
気になるなら自分で調べてね＾＾ スレ違い
はいはい、ジエンご苦労様。
754 ：
仕様書無しさん ：2011/02/05(土) 20:18:25
ぎゃはは、糞がうんこなすりつけあってるわ
こんどは見えない敵と戦い始めました。
>>751 へぇ、例外って遅すぎると使えないのか。なぜ？
>>756 今のCPUの何万分の1、いや何十万分の1の遅さの
CPUを想像してみろよ。本当にそれぐらいの差があるんだよ。
>>757 だからさ、なんでそれが例外を使えない理由になるの？
例外以外の処理も同じように遅いんだろ？関係ないじゃないか。
>>757 いや、だからそれと例外が使えないのはなんの理由があるのよ？
うるせーよバカども
あーやっぱり32ビットのコがいたのねｗある意味安心した。
>>728 > メッセージ駆動がよく分からなかったので
> Windowsのソース見せろと思った。
X11のソース読めばよかったのに
あるいはSmalltalk-80でも可
つかバッチ処理でもなきゃメインフレームから組み込みまで
764 ：
仕様書無しさん ：2011/02/05(土) 20:43:49
ありゃりゃ、例外を語ろうとすればするほど
>>758 仕組み上、例外処理を行うほうがほんの少しだけ処理が多く必要になる
ここは理解できてるかな？
つってももちろん最近のPCで動かしたりする分には体感できるような差は生まれないので
昨今のパソコンの上なんかで動かすようなものを作る分には気にすることでもない
ここまで知ってたら、あとは大雑把に考えるとわかると思うんだけど、
0.00001秒と0.001秒だと、時間的には100倍かかっていても、
人間じゃ差なんか意識するような差じゃないから気にならない
でも、普通は0.00001秒で出来るようなことも、1秒かかってしまうような
極端に遅い環境では、1秒と100秒となってしまって、差が体感できるくらいに開いてしまう
751の言わんとしてるとこは、だいたいそういうことだと思うよ
そういう極端な環境では、たとえ例外が使える言語を使っていても(まずありえない前提だろうけどｗ)
例外を使わない選択肢を、とる必要はあるのかもしれないけどね、っていう皮肉的なお話ｗ
ふーん、でそんな違いが8086とcorei5？であるとわかるんだ。スゴイねーｗ
でもさ、例外を処理したことよりずーっと速度が気になることは多いから
どっちかってとメモリの都合でnew禁止ってのが、まだ有りうる。
いや、だからいま飛んでる戦闘機とか16ビットのAdaで動いてるし…
で、それがなにか？
組込み豚はこのスレには必要ないと思う
わかんなきゃそれでいいやｗ
774 ：
仕様書無しさん ：2011/02/05(土) 21:13:07
あらららら、Oracleに吸収されたOSメーカが作ったjava言語を使っているくせに
まとめて他所にいけよ
>>771 >環境の問題として例外が利用できない
だからそんな奴はいねーと言ってるんだよｗ
777 ：
仕様書無しさん ：2011/02/05(土) 21:15:54
>>772 ん、throwされたときのコストはカーネルオブジェクトが起動される分だよな
きっと
時々沸くけどなｗ
779 ：
仕様書無しさん ：2011/02/05(土) 21:18:46
例外処理の内部は
「言語の例外機構」にはものすっっごぉぉおいオーバーヘッドがあるんだろうよ。
781 ：
仕様書無しさん ：2011/02/05(土) 21:20:58
同期でthrowしたら、時と場合によっては永遠にはりついていつまでもデバッグできないもんなあ
>>779 いや、非同期関係ないっす。マシンの例外と混同しちゃいかんですよ。
>>779 お前が言ってるのは、このスレのテーマの例外とは
全くの別物だ。
>>780 例外はただのエラー専用戻り値でしかないので
オーバーヘッドは皆無。
>>777 いやいやいやいや。
カーネルとか関係ないから。
C++ の例外は OS 無しでも動くから。
785 ：
仕様書無しさん ：2011/02/05(土) 21:25:49
いや、コンパイラ内部では、スタックにそれまでの状態をがばばば～と積んで
Javaを目の敵にしてるヤツが居るけど
787 ：
仕様書無しさん ：2011/02/05(土) 21:27:06
>>784 そっすか。つうことはスタックに積み込んで、次のプログラム実行アドレスを
throwのブロックの先頭に仕向けるだけなのかな
>>785 コンパイラ内部じゃスタック積まんよｗ
メソッド呼び出し時に例外用に暗黙の引数がひとつ？増えるだけ。
メッセージなりトレースなり、付加情報を用意してやる必要とかもあるかんなー
ただ識別子のリテラルを返してやるような場合よりやる事は多いよ
まぁそんなのが問題になるような環境では、
そもそもスレで話題になってるレベルの高水準言語自体選択肢にゃならんｗ
>>772 そう解釈したいのならそれでいいよｗ
理解できてる人ならそもそも
>>758 なんて疑問持たないっしょ
>>786 彼の中ではそれが限界なんだよ。そっとしといてやれ…。
perlふうに書くと
perl風ってのは書き間違い。
>>788 そんな実装見たことないなぁ。
今は戻り先アドレスでテーブルを引く「テーブルアプローチ」による実装が主流。
っていうかそれ以外の実装は Windows 上の古いコンパイラでしか見たこと無い。
>>793 つまりより効率的に
速くなってるって事か。
>>793 俺は古いC++のlongjmpでの実装しかしらんかったけど
>445にあるのでその表引きと戻り値のを知った。
例外がCPUをうんと使って新しい環境でしか使えないから
>>796 ホットスポットのど真ん中で例外出しまくる仕様とか無い限り、
例外のオーバーヘッド議論は意味無いだろうな。
やらなきゃいけないことが全部戻り値で表現できちゃうってのがね
やらなきゃいけないことがifとgotoで表現できちゃうってのがね
例外はそんな大層なモンじゃなくてシンタックスシュガーだと思えばいいじゃん。
コード上に処理がでねぇってのも例外作った奴にセンスがねぇよな
コード上に処理が出ない＝処理を書いてなくてもエラーチェックされてる。
>>802 する必要のない処理までもしかしたらエラー返してるかも・・・
って気にしなきゃいけないじゃん
なんでもやりゃいいってもんじゃなくね？
例外の思想がいまだによくわからん
所詮セミナー向け言語だからな
>>803 する必要がないと思ったのなら、
エラーを無視するコードを書けばいいだけ。
エラー無視するということは本来危険なことなので、
無視するならばちゃんとアピールしなければならない。
だからなんの問題もない。
>>804 お前難しく考えすぎ。
例外が発生したときにやることなんて殆ど無いんだよ。
なぜなら言語側でやるべきエラーチェックをやってくれるから。
例外を使った場合、人間がやることは
1.関数でオープンしたリソースのクローズと、
2.必要な場合にエラーをログなど出力することと、
3.復帰可能な場合に、復帰させるだけだ。
1はクローズするリソースがなければ不要
2はログに出力しないのなら不要
3は復帰されないなら不要
ということで例外を気にすることはすごく少ないんだが。
これが戻り値だったら、毎回ifチェックを入れて
戻り値の型と値なんにするか？って関数ごとに悩む必要があるわけだがな。
>>808 > いま、そんな話してないよね
してるじゃんｗ
↓
> する必要のない処理までもしかしたらエラー返してるかも・・・
> って気にしなきゃいけないじゃん
最近の言語って言語開発者に「明示的アピール」ってのが頭にないよね
>>809-810 そんな話してないじゃん
現になんにも書かなくて例外は吹っ飛んでいくのが事実だろ
>>812 明示的にアピールがしたいのなら
アセンブラ使って書けば？
そうすれば、newしたときに
メモリ確保する方法とか
明示的に書けるYO！
>>813 > 現になんにも書かなくて例外は吹っ飛んでいくのが事実だろ
吹っ飛んでいくってお前は例外を何だと思ってるんだ？ｗ
吹っ飛んでいくのはCPU例外などの割り込みの話だ。
今個々でみんなが話している例外は
呼び出し元関数にしか返らない。
呼び出し元関数で何もしてない場合も、
その呼び出し元関数にしか返らない。
結局はエラーの時にreturnしているのと同じなんだよ。
お前はreturnを吹っ飛んでいくと言うのか？言わないだろ？
>>815 馬鹿だろ元のレスからの流れ読めよ
話するの面倒くせーなーお前
派遣先すぐクビになるっしょ？
ほんの数レス前の書き込みすら忘れるとかにわとりかなにかかよ
>>816 面倒くさいならすぐにやめればいいじゃないかｗ
お前の人生と同じだよ。
ま、実際内容に関して反論のレスはしてないが、
なんだかそれを「例外」と同じ言葉で呼ぶから
820 ：
仕様書無しさん ：2011/02/05(土) 22:36:04
おいおい、喧嘩するなよ、こんなちまちましたことでさあ
>>804 > ちなみに０徐は仕様で明示的にカットするべきであって
その考えは駄目。
ソフトウェアにバグがなければが前提になってるから。
バグがないソフトウェアは存在しない。
>>818 てめーはにわとり程度の脳みそしかねーんだから議論に参加するなよ
>>821 はぁ？
なんで０徐がそういう扱いになっちゃうの？
馬鹿？
>>822 お前はとっくに議論から逃げたねｗ
どうでもいいことばっかりいってる。
>>823 そういう扱いにならない理由がないだろ。
それとも納得させられるだけの理由があるのか？
0除算しようと思ってなくても
バグで0除算してしまうことなんてよくある話。
その時に何が出来るか、それすら思いつかないか？
バグを確率で考えてる？
>>826 確率で考えてると言ったときの、お前のレスと
確率で考えてないと言ったときの、お前のレスを
両方言ってみ。
828 ：
仕様書無しさん ：2011/02/05(土) 22:47:44
(^ー^;) 熱いね
829 ：
仕様書無しさん ：2011/02/05(土) 22:48:37
>>825 それはないでしょう。ゼロdivはどんなことあっても阻止するコードに
しなきゃあねえ
>>829 だから、それはバグをなくすことに等しいんだよｗ
バグで0除算を起こした時に、
何が出来るか思いつかないの？
場合分けできれば、バグリにくい。
if( a != 0 ) { b /= a; } else { throw "0で割るんじゃねえボケ"; }
833 ：
仕様書無しさん ：2011/02/05(土) 22:51:01
? (=_=;)だって0divに絶対しないようにすればいいでしょう。
>>826 0除算を防ぐために、
i = a/b の代わりに
i = (b == 0) ? 0 : a/b
というコードを書く馬鹿を見たことがあるよｗ
835 ：
仕様書無しさん ：2011/02/05(土) 22:53:01
>>831 想定外も含めて設計しないの? (・へ・;)
まずは仕様の正常系だけ、ごりごりって
>>833 どうするんだ？
そのやり方を言ってみ
言っとくが、最初からバグって話なんだから
お前の行ったそのやり方を「やってない」場合の話だぞ。
そのやり方をやってない場合はどうするんだ？
バグで0除算したときに、システムとして何が出来るか
何も思いつかないか？
837 ：
仕様書無しさん ：2011/02/05(土) 22:54:45
サンコン演算子ね(^▽^)/
>>835 想定外ってのは設計に含めるのを忘れたから、
「想定外」というんだよ。
想定外を設計に含めた時点で、
それは想定外じゃない。
人が作る物にはミスはあるでしょ。程度もんだけど
840 ：
仕様書無しさん ：2011/02/05(土) 22:55:44
>>836 だからさ、0divになるシステムはまず、品質的に問題外だよ。
そんな前提で出されても困るっす
842 ：
仕様書無しさん ：2011/02/05(土) 22:56:56
>>838 だからさ、想定外をきちんと想定内に取り込むことができないと
システムなんて設計できないでしょうが
>>840 > だからさ、0divになるシステムはまず、品質的に問題外だよ。
問題外と言われたところで、世の中にバグがない
ソフトウェアがない事実に変わりはない。
お前の前提ってのは、現実的にありえない話だから
それこそ問題外だよ。
>>842 だから、バグで0で割ったときを
想定するって話だろ？
お前はバグが入った場合を想定してないのか？
そりゃだめだろｗ
0divとかを隠すために言語の例外ができたんじゃないの
バグ隠蔽みたいな使い方してる人がいるからね
戻り値でエラーを返しているのに
849 ：
仕様書無しさん ：2011/02/05(土) 23:01:32
[unko@hoge test]$ hoge
分かって使ってればいいけど、
851 ：
仕様書無しさん ：2011/02/05(土) 23:03:07
>>844 バグが入った場合。想定するというか、一発でキリリと動かす天才はまだ二人しか
見たことないからなあ。想定はしなくとも、バグは怒涛のように襲ってくるなあ
852 ：
仕様書無しさん ：2011/02/05(土) 23:04:52
>>848 それは、0divの混ざるシステム以下の話ですなあ
>>851 天才なんてまずいないんだし、
そういうときに、できることに何があるか
気づける人になれよ。
バグが出たら頑張ってバグを直します！じゃだめなんだよ。
頑張るなんて当たり前でなんの解決にもなってない。
バグが出ることを想定して、そのバグの原因を
すぐにわかるような、書き方をしたりシステム設計をしないといけない。
その方法の一つが戻り値ではなく例外を使うってことなんだけれども。
854 ：
仕様書無しさん ：2011/02/05(土) 23:11:51
>>853 うーん。それならば俺の場合は例外よりもシステムログのほうが強力かな
>>854 お前のシステムログには、0除算エラーのログが記録されるのか？ｗ
使い方よりは考え方を教えないと...
857 ：
仕様書無しさん ：2011/02/05(土) 23:15:01
>>855 その直前まで動作したとこまでは追跡できますからねえ
だけど0divなんて恥ずかしくてだせないし、
>>849 のような表示が出るから
すぐ分かるだろう。ちがうか?
隠蔽されると見つかりにくいこともあるでしょ
859 ：
仕様書無しさん ：2011/02/05(土) 23:16:53
なんか、舞台がままごと開発のテーブル上の議論みたいで楽しいよ
> その直前まで動作したとこまでは追跡できますからねえ
そういうログを表示するように書いたのなら当たり前。
今はそれぐらい何も書かなくても追跡できないといかん。
> だけど0divなんて恥ずかしくてだせないし、
>>849 のような表示が出るから
> すぐ分かるだろう。ちがうか?
違うな。エラーの起きたファイル名、関数名、行番号がでてない。
861 ：
仕様書無しさん ：2011/02/05(土) 23:17:36
「浮動小数点演算例外です」
863 ：
仕様書無しさん ：2011/02/05(土) 23:19:16
ええ?除算にひっかければすぐでしょうに。あんた本当に頭わるいね
864 ：
仕様書無しさん ：2011/02/05(土) 23:20:30
それに、設計された作業でしょう。演算している箇所の特定はすぐにできるでしょうよ。
865 ：
仕様書無しさん ：2011/02/05(土) 23:21:54
ああ、それとも大規模俺様main一発3万行プロジェクト?
>>863 まさか 「/0」で検索するのか？ｗ
普通0の部分は変数だろ。
/で検索したところで、一体どれだけの箇所に
引っかかるんだか。
なんかだいたい見えてきたな。
お前、数十行程度のコードしか書いたことないだろ？
たしかにその程度じゃ、スタックトレースの詳細なログの
利点はわからないだろうな。
0で割ったときの動作を知らないとか
例外でもアサートでもcoreでも何でもいいわ。
0除算なんて入れるほうが悪い。
>>868 動かないにしても、
「浮動小数点演算例外です」 とだけでるより、
詳細なスタックトレースをログファイルに
書きこむようにしておいたら問題の解決も早くなるよ。
なにせ例外を起こした行番号が出力されるのだから。
>>871 運用中の話をしてるのに
デバッガ上で動かすわけ無いだろｗ
ちょっと話がずれるけどデバッグビルドで配布するよな？
874 ：
仕様書無しさん ：2011/02/05(土) 23:50:44
>>871 俺はデバッガかったるいからやっぱりシスログっすね
grepの検討もつかない人たちなのかよ、やれやれ、本当に無能というか
お前ら素人だろう。 divの変数を設計上で識別できるルールにすれば
一発でgrepにひっかかるよ。それがすぐ言いたかったけど
2chにさるさんバイバイといわれてかけなかった
>>873 世の中でリリースされてるアプリの
ほとんどはリリースビルドだよ。
調べてみ。
怒られるのは、お前の会社が馬鹿だからじゃね？
なんで構造体なんて使うんだ！みたいなのと同じレベル。
それ以外にやり方を知らないんでしょ。
876 ：
仕様書無しさん ：2011/02/05(土) 23:53:10
あ、そうか、おまえら底辺のプログラマかいな
>>874 > divの変数を設計上で識別できるルールにすれば
> 一発でgrepにひっかかるよ
その俺様ルールを言ってみｗ
一発でgrepに引っかかる、その名前を。
割る数1、割る数2、割る数3
879 ：
仕様書無しさん ：2011/02/05(土) 23:58:45
>>877 お前らw 馬鹿のギガビットサイズだな
俺様ルールってw 仕様レビューで通れば正式なルールだよ、べつにどんな名前でも
いいんだよ。識別ができればさ。それも聞きたいのかw がはははははっ
>>879 はい、聞きたいです。
0除算の原因になるかもしれない変数に付ける名前
しかもgrepでたくさん見つかって、どれが原因だ！？って
ことにはならないんでしょう？
881 ：
仕様書無しさん ：2011/02/06(日) 00:00:48
デバッグビルドでの配布ってwwwwww
>>879 デバッグビルドは
実行するために開発環境が必要だったり、
ライセンス上配布できないファイルが含まれていたりするので
通常はリリースビルドで配布します。
書けば書くほどバグを生むんだから余計なコード書かずにテスト項目書け。そしてテストしろ。
テストだけ作っとけば客が満足するならな！
どうせ想定外のエラーに対処するコードにもバグが含まれてるよ。
887 ：
仕様書無しさん ：2011/02/06(日) 00:04:45
double saru_880_unko; とかにすれば一発だろう
>>880 saru_880 というぷれふぃくすがつけば割るほうの変数とする。とか決めるだけ
grepにはファイル名、行番号が出てくるオプションがあるからわかるだろう。
てか、割り算するべたなコードをうめこみまくるように作るのかい?
例外を語る人のくせになんでひとつのメソッドに集約できないの?
集約したら一発でみつかるよ
>>887 で、saru_880_a、saru_880_b、saru_880_c、saru_880_d、
みたいにgrepでたくさん見つかるんだろ？
そのうちのどれが原因なんかわかるのかよ。
っていうか割る数に使うからってそんな変なプレフィックスを付けるという
コーディング規約つくるなよ。聞いたことねーぞｗ
え？例外肯定派はバグ（しかも仕様の）を例外でキャッチするために例外書いてるの？
バグはバグだろ？
892 ：
仕様書無しさん ：2011/02/06(日) 00:10:20
>>889 まともなをただで教えるわけにゃあいかんのだ。
893 ：
仕様書無しさん ：2011/02/06(日) 00:11:15
>>889 >>887 の下のほうをよく読め。なっ。0divがたくさん出てくるような
つくりがまずだめだぞ。
>>890-891 頭が固いなｗ いや悪いなか。
なんで例外にスタックトレース出力の機能があると思ってるんだ。
スタックトレースはデバッグのための情報だろ。
>>872 運用中にエラーの起きたファイル名、関数名、行番号なんぞ出してどうすんだ？
896 ：
仕様書無しさん ：2011/02/06(日) 00:12:01
０除算が起こる可能性のある箇所はgrepとかそういう話をする時点でズレてる
>>893 割り算をするための関数を使って、
場所を一箇所に集約したところで、
解決したい問題が、どこで割り算をする関数を呼び出したかに
変わるだけで、なんの問題解決にもなっとらんよ。
899 ：
仕様書無しさん ：2011/02/06(日) 00:13:48
まともで頭が良い人たち
>>890 >>891 ぷっっっっっっっっっっう。ど馬鹿なのねな人
>>894 バグを追求するために例外があるわけじゃないのよん
>>887 0除算を静的解析で簡単に検出できるだって？
ほんとだとしたらあんたすげー大金持ちになれるよ。
>>897 > 組み始める前に計算式みて気がつかなきゃならないレベル
気づかないからバグが起きるわけで、
お前が言ってるのはバグがないソフトウェアを作ればＯＫと言っているだけ。
そんなものは現実に存在しない。
>>899 スタックトレースはバグを追求するための機能。
それが例外に追加されている理由を
考えたことがある？
>>901 バグをハンドルするためのコードにバグが入る可能性があるんじゃ意味ないじゃん。
むしろ余計なコードが増えた分、バグが余計に増えるわ。
904 ：
仕様書無しさん ：2011/02/06(日) 00:16:02
>>898 呼び出し元の解析もできんのかね。そんなに割り算をするメソッドを
5000箇所ぐらいから呼び出しているようなシステムなのかい?
だっだめだ、笑いすぎて腹が痛い
>>903 例外処理のためのコードは
極めて少ないから、
バグの入る可能性は極めて少ないよ。
どちらが可能性が高いかの問題。
数日前から思ってたんだけど
>>904 割り算を沢山使用するシステムは
ありえないっていってんのか
908 ：
仕様書無しさん ：2011/02/06(日) 00:18:20
>>898 は自分が書いた0divのバグで心身共に衰弱状態におちいってないか?
俺でよければ相談にのるぞ
戻り値エラーだったら、そのエラーハンドルコードを
バグを例外でキャッチするとかどこまで頭悪いの？
911 ：
仕様書無しさん ：2011/02/06(日) 00:21:10
>>907 使うよなあ。物によっては割り算多用するよ。
A/Dコンバートなんかのシステムの時には使ったなあ。
だけど0divは絶対起きなかったぜ。納品してから15年以上も立つがクレームに
なったことはないなあ。
あなたが組んだプログラムはあなたが組んだとおりに動作します。
0divが起こるのはあなたがそのように組んだからです。アーメン
今話してるのはリリース版において想定外のエラーに対処するために
>>904 メソッドのコールに至るパスが5000通りなら
別に珍しくもないと思うんだけど
何がおかしいの？
>>911 いや、俺が起きなかったから
他に人も起きるはずがないという考えでは。
トラブルを解決することはできなんか
一人で作るような小さいプログラムでしか通用しない理屈。
お前らほとんどが、例外が分かっていないだろう。
>>912 別にデバッグ版でもいいよ。
デバッグ版だけスタックトレースを
ファイルに出力するような実装でもいい。
>>915 は釣りとわかった上で
気づかないふりしてレスするようにｗ
>>916 デバッグ版ならデバッガ使えばいいじゃん
919 ：
仕様書無しさん ：2011/02/06(日) 00:26:19
>>914 ループで呼び続けるようなシステムなら5000なんて即いっちゃうよねえ、たしかに。
仕様が見えないので想像でしかいえないけど、数値計算のシステムなら
確かに笑えないものはあるかな
>>918 デバッガ上で動かすのと
デバッグ版ビルドの実行は意味が違うぞ。
その区別ぐらいつけろよ。
>>920 gccでデバッグ情報アリでコンパイルすると
デバッガで実行して0除なんかで止まったときにどのファイルの何行目で止まったかわかる。
922 ：
仕様書無しさん ：2011/02/06(日) 00:32:59
まとめ
>>921 デバッガ上で実行しない場合は？
たしかデバッグ版で納品しろって怒られたやつが
上にいただろ？
>>922 そんなことやったって、
ということにしたいって
お前の願望が滲み出るだけだよ。
逆効果ｗ
925 ：
仕様書無しさん ：2011/02/06(日) 00:35:13
>>921 俺デバッグオプション嫌いなのよ。リリースビルドと動作が違う可能性が
あるし。物理的にバイナリがぜんぜんちがっちゃうわけでしょう。
デバッグバージョンで動作していたのに、リリースで動作しないっていう
話はありごとだよ。やっぱりしつこいけどシスログ最強
そして戻り値厨はシステムがダウンするまで
927 ：
仕様書無しさん ：2011/02/06(日) 00:37:44
>>926 全部 void hoge()パターンで書く人ですねw
>>925 じゃあ、デバッグ版ビルドで例外使って
想定外の例外が起きたときに
シスログ出すようにすればいいじゃん。
ほら完璧ｗ
これだけは言っとく。
930 ：
仕様書無しさん ：2011/02/06(日) 00:39:23
>>928 うわぁ、やっぱりシンプルが一番。
デバッガをたよる技術者に切れ者なし
>>925 メモリ周りで起きるセグメンテーションフォルトなどの例外がデバッグオプションのあるなしで変わってきたりはするな。
そういうときはElectricFenceなんかのメモリ破壊検出ツールもあわせてテストするんだよ。
933 ：
仕様書無しさん ：2011/02/06(日) 00:41:11
>>931 メモリ破壊もクラッシュする位置さえわかれば即特定できるからいらないね。
ただ、ひでえ品質のシステムでC/C++のポインタがらみのバグがてんこもりの
やつでかつ再現性がないバグだったら俺は夜逃げします
Java使えば、メモリ破壊なんて
935 ：
仕様書無しさん ：2011/02/06(日) 00:43:28
>>932 初心者のころは世話になったな。しかし、効率が悪すぎるよ。
>>932 は
神のように使いこなしているんだろうが、俺はめんどい。
ブレークポイントを的確にセットできたとしてもかったるいなあ
937 ：
仕様書無しさん ：2011/02/06(日) 00:44:25
>>934 いや、俺は破壊しないけど、破壊王たちが作ったものをデバッグする気は
さらさらないのよ。てめえで直せってね。
938 ：
仕様書無しさん ：2011/02/06(日) 00:45:11
いつしか例外スレは 「デバックテクニックスレ」になりました
例外はコードの記述量が
例外をデバッグに使うというか、
>やってはいけないこと
>>941 それは、正しい例外処理を行えってだけで
例外処理が駄目という話じゃないよ。
例外を全否定してるわけではないけど
>>944 ここにもたくさんいる。
だからどうした？
そういう書き方が気にいらない
気に入ってもらう必要なんて無いだろｗ
こう理解できない馬鹿にうまいこと教える術はないものか
理解する気がまるで無いのだから
長年戻り値でやってきた
C++にfinallyが無いのが苦痛ならgotoで代用すればいいじゃない
うわー、キタネェコードだなｗ
953 ：
仕様書無しさん ：2011/02/06(日) 11:20:34
ぷぷぷぷぷーーーーーーーーーーーーーーーーーーーーー
954 ：
仕様書無しさん ：2011/02/06(日) 11:21:17
言語ごとのローカル仕様もしらんでよく例外語れるねw
955 ：
仕様書無しさん ：2011/02/06(日) 11:23:06
ノミの脳みそが猿を馬鹿にする図式に笑った
>>953 デストラクタはクラス終了時の処理
finallyは関数終了時の処理
この違いぐらい知ってください。
957 ：
仕様書無しさん ：2011/02/06(日) 11:42:28
>>956 知ってるよ。C++ではfinallyはないからデストラクタで処理するしかないだろう
958 ：
仕様書無しさん ：2011/02/06(日) 11:44:20
それに例外を搭載したOOでgotoつうのうもどうかね
959 ：
仕様書無しさん ：2011/02/06(日) 11:45:29
>>956 はC++にfinallyが無いことをしらなかったようです
>>957 デストラクタは関数終了時に呼ばれないんだから
変わりに使うことはできません。
finallyならcatchの時にやればいい。
つかC++はOOPしてるとは限らんのだが・・・
962 ：
仕様書無しさん ：2011/02/06(日) 11:49:37
>>960 致命的エラーならばデストラクタでリソース廃棄して終了しないと
リークしちまうよ。君はOracleに吸収されたjavaをつかっているから
そんなこと考えなくても良いんだろうけどね
>>957 例外起きたらそのクラス死んでまうのん？
言語では規定されて無いけど、実装されてる。
965 ：
仕様書無しさん ：2011/02/06(日) 11:51:00
>>961 OOPしないのならべたCのほうが効率がいいよ
OOと例外は直接関係しないのだが．．．
現代的な例外やcall/CCはLISP系だよな
968 ：
仕様書無しさん ：2011/02/06(日) 12:04:26
>>951 俺は猿でよくわからん。以下の間違いをなぜ間違いなのか
猿の俺にもわかるように説明してください。おねがいします
void some_func(){
try{//...}
//このキャッチハンドラは間違いだそうだ
catch(void*){...}
catch(ArrayErr &){...}
catch(RangeErr &){...}
catch(const char *){...}
catch(void (*pf)(const char*)){...}
}
969 ：
仕様書無しさん ：2011/02/06(日) 12:06:51
>>964 俺のもっているC++プライマーにもそんなこと全く記述されてない
こまったね第2版だからいかんのかなw
>>968 「間違いだそうだ」とか言われても何が間違いなのかわからない
単によくある独自拡張なだけだろ。
以下、このスレはgotoを正しく使えないプログラマ多いねスレになりました
975 ：
仕様書無しさん ：2011/02/06(日) 12:39:08
例外を正しく使うためにはRAIIが必須ってこと？
979 ：
仕様書無しさん ：2011/02/06(日) 12:44:08
>>974 早く解決してくれよ、このスレの神様、俺猿だからもやもやして
気持ちわるいっす
今MSの昔のマニュアル読んでいたら笑った
キーワード
try*8
catch*8
*8 Microsoft C/C++バージョン7.0では実装されていません
だって
VC++1.0から実装されたのかな
981 ：
仕様書無しさん ：2011/02/06(日) 12:47:54
>>980 直訳日本語で意味不明でわからんのよ、神様のあなたにぜひお願いします
>>981 俺は神だとか名乗ったことないんだけどな。
それに、パッと見ただけじゃ分からんよ。
間違いってのは、コンパイルが通らないってことでOK？
それとも、コンパイルは通るけど良くない書き方ってこと？
>>983 その質問に答えたとして、
お前は適切なことを言えるのか？
適切ことが何かを知っていれば、
コンパイルが通らないのか良くない書き方なのか
聞くまでもなくわかるだろ？
>>985 そこまで解ってるんだったら
983の代わりに解説してあげれヴぁ？
988 ：
仕様書無しさん ：2011/02/06(日) 13:26:24
>>983 コンパイルは俺もしてないし未確認だけど
よくない(問題のある)書き方らしいが、その意味が知りたい。
きちんと理解できないと、神のように例外をつかいこなせないじゃない。
だからがんばって猿なりに理解します。よろしくお願いします。
989 ：
仕様書無しさん ：2011/02/06(日) 13:30:23
>>985 という優秀な方が登場しましたが、俺はやっぱり神さまにおねがいしたいです
990 ：
仕様書無しさん ：2011/02/06(日) 13:34:02
そして予想どおりスレの流れがフルgcでかたまりつつあります
これ、throw "ﾌﾟｷﾞｬｰｰｰ！";ってやるとどこでキャッチされるの？
>>991 throwする側はどこでキャッチするかを考えてはいけない。
throwする側は異常事態が起きたことを親関数に返すだけ。
throwされた例外はその例外に興味がある人。
つまりその例外を処理したい、処理できる人が
キャッチする。
>>992 そゆ意味じゃなくてだな
void some_func(){
try{
throw "ﾌﾟｷﾞｬｰｰ！"
}
//このキャッチハンドラは間違いだそうだ
catch(void*){...}
catch(ArrayErr &){...}
catch(RangeErr &){...}
catch(const char *){...}
catch(void (*pf)(const char*)){...}
}
で、キャッチされる場所は
catch(void*){...}
catch(const char *){...}
のどっちよ？ どっちでもキャッチできるぞ。
だから、どっちに行くかが曖昧であまりよろしくないキャッチ句なんじゃねーの？
先に書いた方に決まってるだろ・・・
>>993 void*がExceptionの代わりになるみたいな勘違いしてないか？
(void*)でキャストしないかぎりchar*がvoid*でキャッチされるなんてありえないよ。
>>993 がヒントを述べていますね
どのポインタ例外も標準変換を適用することで void*と称号するらしいです
プライマー二版の時点では警告を出すべきと書いてありますがおそらく
VS2008とかg++ではでるのかな?
997 ：
仕様書無しさん ：2011/02/06(日) 14:11:28
ああ、スレ終了までに解決してよかった～
999 ：
仕様書無しさん ：2011/02/06(日) 14:15:05
プライマーによる正解の並びだそうです
1000
1001 ：
１００１ ：
Over 1000 Thread このスレッドは１０００を超えました。