◎正当な理由による書き込みの削除について： 生島英之 とみられる方へ:例外を正しく使えないプログラマ多いね。 その7->画像>5枚
動画、画像抽出 ｜｜
この掲示板へ
類似スレ
掲示板一覧 人気スレ 動画人気順
このスレへの固定リンク： http://5chb.net/r/prog/1306646249/ ヒント： http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。
例外にまつわる内容であれば、不満でもネタでも主張でもご自由に。 >>980 を超えたら新しいスレを準備してください。 http://hibari.2ch.net/test/read.cgi/prog/1298059471/ むしろ例外の扱いが微妙なC++のほうが話題多そう。
javadoc形式のタグは他言語でも似たような形式で流用されてるの多いしJava前提ってわけじゃなくね
まともなコードヒントが出ない場合、発生する例外がわかりにくくて手間かかるわ
javadocはもう一段進化するべきだな。
/**
自動生成で事足りるし、そこまで手間だとは思わんな
つか元々言語とは別もんの機能なんだから、
> 言語に依存関係に無いはずの
コメントの内容は依存したらいけないだろ。
連動も面倒もどうでもいいから
>>11 >コメントの内容は依存したらいけないだろ。
本来そうなんだけど、PostScriptってページ記述言語が有ってじゃな…
>TCPのデータ領域をTCP階層で監視するようなもんだぞ。
FTP...
IPv6に成ったら、FTPは撲滅して、scpかbit torrentに移行すべきだな。
>>9 どんな古いIDE使ってるんだw
時代遅れにも程があるぞ
>>14 コメントを変えると同時に引数名が変わったり、
引数が削除されるIDEがあるのか最近は凄いな。
コードで表現できてるのを、コメントで二度書ききなきゃならないコードを、プロは書かない。DRYに反する。素人の糞コード。
>>16 うん。だから
>>6-7 のように
コメントとコードが一体になる方がいいと言ってるわけだ。
>>17 >>6-7 は3つの点でピントがずれてる
まず1点目
> * @return true if a valid chess move or false if invalid
> boolean isValidMove(int theFromFile, int theFromRank, int theToFile, int theToRank)
何したいコードかよくわからんが、仮にそのコメントで意味が通じる、と
そう仮定するなら、メソッド名をisValidChessMoveと書けばいい。
命名センスがなく、うすうすその自覚があるから、コメントで言い訳したくなるんだろ？
変数名も同様。
7に至っては本末転倒。コードで充分、が結論になるようにかけばいい。
そして2点目
tell, don't askだろ。このコードのクライアントはvalidか尋ねてどーすんの？っていう。
設計がへぼいから、いまいち何したいかわからんコードを書くことになる。
だから、コメントで補わんとにピンとこないだろうという感覚で、
コメントへと逃げたくなるんだろ。
そして3点目。
スレタイの「例外」に全く関係ない。
コメントに「何をするコードか」ばかり書いちゃう奴は修行が足らん
>>19 お前はピントがズレていると言ったが、
本当にピントがズレているのはお前の方だ。
コードの中身に文句をつけてどうする。
それはあくまでサンプルであってコードに意味はない。
別にコードの内容を指摘されて悔しいから言っているわけじゃないぞ。
なぜならそのコードはwikipediaから拝借したコードだからだ。
http://ja.wikipedia.org/wiki/Javadoc コメントというか、関数名の頭に描くべきものは、
引用元がどこだろーと、下手なコードが下手なことに変わりはないなw
コード批判はしてるかもしれんが、より本質的には発想批判だろ。
>>6 の思考は、同じ名前二度書かせるな→まとめて書いちゃえ
というのが中途半端なんだよ。
コメントなくても通じるコード書けば十分だろ？っていう指摘。
doclet捨ててなおAPIドキュメント作りたいんなら、わかりやすいコードだけ書いて
リフレクションでAPI生成してろよ、
って普通思うんじゃねーの。
無駄だって問題提起しながら、そこで出した解決策がこれまた無駄だから揶揄されてるんだろ。
> コメントなくても通じるコード書けば十分だろ？っていう指摘。
特に戻り値は型しか書いてないから、
それは、名前の付け方が悪いんでねーの？
コードを読めば分かるというのは、
>>26 それはプリミティブで返すからだろ。
エリックエバンスの本とかにも分かりやすい説明あるぞ
>>29 違うだろ、コードの使用者の感心ごとは、コードの中身じゃない。契約だよ。
中身なんか読まずに済ませたい。
読む必要がないよーに、シグニチャを設計するんだよ。
それが良いコード。
>>27 > コメントで書く説明を、書かなくていいよーな引き数名にすれば済むでしょ。
> そーいう発想で書いてみ？
じゃあお前はsprintfという関数の引数として
何が使えるかを、どうやって引数名に含めるんだ？
double pow(double x, double y)
つか、関数にする理由は、
>>32 先に白状しとくと、俺はC使いではないんで、妄想込みだから脳内保管してくれ。
推測するにsprintfは、
フォーマットとかメッセージを例えば渡すんだろ？
だったら、型抜きで書くなら
sprintf(message, format)
あたりだろ。
messageの型はobjectなのか？各型ごとにオーバーロードしてるのか？その辺りのニュアンスはC使いじゃないんでよーわからん。言語特性にあわせてよろしく定義されてるんだろ。
戻りはvoidあたりか？
で、format辺りは文字列でやってんだっけ？そーすると渋々ドキュメンテーションコメント書く系統の設計になりそうだなこりゃ。
ま、こりゃコメント書かんとダメだな、ちっ、っていう例だと思う。
>>33 なんか怒らせたっぽいか？すまんな。
だが現場の経験から話してるぞ。
ドキュメンテーションコメント見ながら、コード書く奴がいるのか？を冷静に思い出してみてくれ。
言語そのものといっていい組み込み関数だかAPIだかライブラリの話じゃないぞ？
おまいやおまいの同僚が、昨日や今日書いた、あるいは今さっき修正してコミットしたての、そのコードをだ、
自分があるいはとなりの席の奴が使うとして
ドキュメンテーションコメントを確認して使うのか？それは本当かい？
開発プロセス次第かもしれんが、スクラッチ書いて、顧客に見せてフィードバックもらって、設計改善して、、
コードの内容を素早く把握できるように
>>35 引数の制約もコード見て調べるんか？
例えばベジェ曲線を計算するメソッドが有ったとして
同一座標が重なってはいけないという制約があるとする。
それをコメントで一言
//頂点が重複する場合は例外が発生する
と書けばいいものを、
反復で変化する値を追い分岐の変化を追って
例外に至る原因となる引数を特定するのか。
>>34 x コードを読めばわかる
o シグニチャ見ればわかる
だな。
コードコード言いすぎて一つの語を複数の意味で書きちらしたおれのミス。
複雑さを隠蔽するために書くわけだからコード本体を使用者に読ませるつもりは当然ないよ。
「頂点が重複する場合は例外が発生するベジェ曲線を計算する関数」って
>>39 その制約を、コードのクライアントが知るべきか？その例外をクライアントが処理すべきかどうか、あたりで変えるかなあ。
つまりバグでしよ？正しいコードじゃおこんねーよ、だったら集約例外でログ吐いとこー方針でAPIには含めない。
業務仕様でしょ？だったらAPIに含める。APIへの含め方は、例外で表現するか、戻りの型？クラス？列挙型？で表現するかは、言語特性次第だな。
実運用上はコードでの表現を第一に考えて「うわーギブアップ！今の俺の実力じゃコ(現実的な時間では)コードで表現出来んわ」となったら、ションボリしながらコメントで言い訳する。で自分にがっかりするw
そうまでして、コメントをスリムにコードでこそ語ろうぜ！という方針の意図は、DRY原則はいうまでもなく、
>>42 ゼロ除算と同程度の話なんだけどな。普通そんな座標は入れないし。
メソッドを呼び出す側としては当然知っておくべき制約。
普通ゼロ除算をしちゃいけないと説明されるから値を渡す側はみんな割る数に0を
渡さないよう気をつけるだろそれと同じ。
で、どちらにしろコメントが不要になることはなく、
コメント書くならば、一箇所だけに書けばいいわけで
コメントとコードが分かれていると
同期を取らないといけなくなるから
一つにしろというのが
>>6-7 なわけだ。
あ、コードの中身はwikipediaの
JavaDocからの引用だからね
0で割ったら無限大になる
>>44 計算によっては1を渡したら0除算になる場合だってあるだろうさ。
そのことを知らせるにはコメントに書くしか無い。
コード見たって、バグかも知れないと思うだろ。
>>47 すまんコメントが必要だとしめるつもりだったのに書き忘れた。
なんか勘違いしてる人がいるようだが、別にコードで全てを語ろうなんて言ってる人はいなくて
そして、関数やクラスを作る人の力量は、
で、関数名で分かるようにしろと言ってるだけで、
結局そもそもの問題。関数の引数とそのコメントの二箇所に
同じ名前が書いてあるのは無駄だから統一しろという
>>6-7 の話をすり替えてるだけなわけだ。
>>48 コードとコメントでコメント信じるのはアホだ
コメントはあれだよ、自転車の補助輪みたいなもの。運痴のやつが、親に支えてもらう代わりに、転ばないよーにつけてる感じ？
@throws RedundantCommentException
@throws ExcessiveCommentException
@throws MisleadCommentException
>>55-57 なにwikipediaにのってるサンプルコードに
文句付けてるんだ？ 恥ずかしくないのか？
@throws Wikipedia厨Exception
大好きなウィキペディアが批判されたと勘違いして感情的になる人間を検知しました。論理的な内容に目を向けるようにしましょう。
@see
>>58 class 58=60自己弁護Exception extends InvalidAttitudeException {}
掲示板 2ch = Repository.Find("例外を正しく使えない...");
そもそも、例外が必要なのって楽したいからだよね？面倒くさいチェック処理とか省きたいから。
例外は用途であって機能ではないけどな。
>>66 > GetLastErrorやらerrnoといったライブラリ、
> 割り込み命令で例外を処理してるし。
うん、だからそういうのを一箇所にまとめられる→楽したい ってことなんでしょ？
って思ってさ。
例外処理本来の用途って意味だと、例外が発生してもプログラム三原則に沿って
動き続けるためだろうなーっとは思ってるんだけどさ。
楽をしたいってのは間違ってるぞ。
>>67 try-catchの事言ってんなら大して、例外処理箇所は変わらんぞ。
例えば、文字列を数値に変えるInteger.valueOfがあるが、
このメソッドは、値が不正なとき例外を出す。
しかし、この例外には何が原因かは情報がない。
原因が何かは、Integer.valueOfに間違った値を渡した
呼び出し元のメソッドしかしらんからな。
だから、基本的にifで戻り値調べて、どの値が間違っています
って書くのと例外処理の箇所は変わらん。
楽になるとすれば、下層のメソッドから上層のメソッドへエラーを
伝えるだけの処理が省けることと、異常のあったループなんかから
抜け出しやすい事。
まぁ、そもそもtry-catchの発端は、C++でエラー情報を戻り値で
伝えられない関数を補助するためだから。
> このメソッドは、値が不正なとき例外を出す。
>>70 そもそも入力チェックに例外を使っているのが間違い。
例外はその名のとおり例外。
通常の処理の流れでありえない＝途中で中断すべき場合に使う物
どの値が間違っているか調べることなんかに
使うべきものじゃない。
>>71 原因が何かってのは、幅に文字が入ってるとか、
高さに文字が入ってるとかだぞ解ってるとは思うけど。
>>72 何から入力させてんの？まさかコンソールから値を入力する事を前提にしてるわけじゃないよね。
GUIならさ、普通数値以外を入力できなくさせることができる訳じゃん。ここで数値チェックなんてそもそも
必要ないわけよ。じゃあ他に数値が入っているべき場所に文字列が入ってる状況は？
そうなるとファイルやら通信データになるわけだ。当然データ構造のパースが走る。
パース処理は浅くはない、パース途中で値が無効だと解った時のコールスタックと、
パースが崩れた原因を知っているコールスタックは距離が離れてる。
そういう場合、いちいち例外投げない数値チェックをするのは、処理が2重になる上
コールスタックのif連鎖がある分無駄でしかないんだよ。
>>73 例外っての出してもらうもんじゃないよ。
自分がわかるんだろ？
分かるやつが、例外の中にその情報を入れて
投げるもんだ。
その結果「例外には詳細なエラー情報が含まれる」ことになる。
やっぱり例外の使い方分かってないよ。
>>74 それはそうだよ。でもそんな話はしてない。
それは、まず例外を受け取ってからの話だ。
君たちはちょっとアセンブラレベルから一回考え直したほうがいいです
>>72 中断するべきかどうかっていうのを起点にするならちゃんと判定しろって思うんだけど
どうなんだ？
例外処理って「なんか起きても動き続けるために」使うもんだと解釈してるんだけど。
＃ 発想としては、ね。そりゃ書き方次第でいろいろ使えるのは分かってる。
>>77 だから、例外の処理自体はC以前の時代からあって、
try-catch使おうが、ハンドラー使おうが、戻り値使おうが
例外処理の内容は昔と同じなんだって。
Begin Sub A
>>77 > 例外処理って「なんか起きても動き続けるために」使うもんだと解釈してるんだけど。
例外処理は、通常の処理とは違う異常事態が起きたことを簡潔な形で伝える物。
伝えるだけ。
伝えた後動き続けるかどうかは
アプリの仕様しだい。
>>81 > 例外処理は、通常の処理とは違う異常事態が起きたことを簡潔な形で伝える物。
俺が「動き続ける」といったのはもちろんその「伝えた」以降の話なんだけども、
ぶっちゃけ「なんかよく分かんないことが起きましたので処理を中断して終了」
っていうのは、バッチ的な解釈なんだよね。
オンライン（リアルタイム）の場合は止まってはいけない。できればバッチの場合
でも復帰して続ける。
銀行ATMで「すいませんがなんか想定外のことが起きたんで停止します」って
話になったら業務に支障が出るわけで。
止まっても問題ない場合は止まればいいと思うよ。でもそれは例外処理の本来
の使い方ではないかなぁと思うんだよね。
まず、throw try catchの概念を捨てて考えたら？
>>84 その概念を捨てて例外について騙ろうって言うのか？
お前、大丈夫か？
>>83 想定外のことが起こったら、停止するしかない。
想定外のこと以外でも例外発生すると面倒なんだけどな。
例外を使おうがそれ以外を使おうが
>>85 ノイマン型コンピューターには分岐と変数となんやらかんやら・・・。
Cωで書けたプログラムがFORTRANで書けないわけじゃない。
HTML5の技術を使わずjavascriptだけで3Dグラフィックスを
書くこともできない訳じゃない。こんな感じでな。
http://jsbin.com/ubiyay/3/edit#preview アルゴリズムがチューリング完全ならどの言語にも依存しないのと同じで
例外処理だって言語に依存しないし、十分語れる。
例外情報が必要とかいうなら、staticな共用データ(共用体)に格納すれば
例外機構の無い他の言語でも用意できるし重要じゃない。
問題は、想定内の事象での例外だな。
>>88 いや残念ながら俺は例外処理必須と考えてるわけではない。
初発は
>>65 だ。
で、まぁ例外処理だって言語に依存しないっていうのはまぁ分かるし、
十分語れるならそれをかたってくれい。
続き
ただ、俺が
>>85 で言いたかったのは
>>1 を無視してまで騙る必要がこのスレに
あるのかってこと。
この板は、相変わらずだな。
お前は口だけでOSを作る上で一番面倒なことは何か理解していないようでしたが？
だから何。
>>95 お前は頭悪いな。自分の文書に違和感は無いのか？
>あんたはトランジスタを、電子の動きを、半導体の作り方を理解して、コンピュータ使ってるのか？
”電子の動き”って、中学で習うだろう、義務教育を受けていれば分かることだが。
それにパッケージになっているLSI（CPU)とトランジスタを比べてどうするだ？（半導体の作り方ってｗ）
>下のレイヤを抽象化するのがエンジニアリングであって、下のレイヤを全部理解してなければ
>わからない、と主張するのはバカのすることだぞ。
まったく分からん、何が書きたいんだ。”下のレイヤ”・”下のレイヤ”って？OSやハードのことか？
抽象化って、理解出来ていないものを抽象化出来るのか？それはただ単に知らないだけだ。
言葉遊びならとりつくろえても技術者としては駄目だな。
それに、そもそも技術者とは抽象的なものを具象化するものだろう。
別に全部理解しろとは言ってないが例外の話なら例外ぐらいは理解して話せ。
フリップフロップ位理解したほうがいかなと、トイレで寝ながら書き込んでいる。
どこまで理解してたら例外を理解してることになんの？
>>92 >>99 またアホなことを。
ハードウェア例外だろうがソフトウェア例外だろうが
割り込み処理で実行しているのが分からないのか？
根本的に割り込み処理が分かってないから
そんな恥ずかしいことを堂々と書けるんだろうな。
お前の書いた例外処理をだれが処理しているんだ？
CPU以外に誰が処理してくれるんだ？
例外処理は、ノイマン型CPUなのに、なぜ急に処理の順番が変更できるんだ？
頭を使って考えろ。
ハードウェア例外とソフトウェア例外以外の
例外処理ってのは、割り込み処理から復帰してから動くコードだよ。
こういうバカって幸せなんだろうなぁ。うらやましい。
> 例外処理は、ノイマン型CPUなのに、なぜ急に処理の順番が変更できるんだ？
例えばゼロ除算とかは、プロセッサの例外をトラップして処理系レベルの例外にするわけだけど、
>>100 お前割り込みの意味しらねぇだろ。
割り込みっつうのは、そもそも割り込みコントローラーが能動的に
割り込み信号をCPUに送りつけ、割り込みベクタを実行させ
ポーリングを排除する。
ソフトウェア例外は、ただの分岐。全く割り込み関係ない。
jgeとかjmpとかintやスタブじゃない命令は割り込みとは言わない。
>>101-106 何を必死になっているんだ。哀れすぎるぞ。
>>101 具体的には？ 言語はなんだ？
>>102 割り込み処理が発生しないと例外処理が出来ないのは納得するんだな。
割り込み処理は、誰が処理をするのか分かるか？
例外から発生した割り込み処理をプログラムが直接受け取るとでも思っているのか？
本当に割り込み処理が分かっていないんだな。
>>104 >処理の順番が変更できないと、分岐もできないだろー。
アホｗ 分岐はジャンプ命令で書いてあるから分岐するんだろうが、それがノイマン型だ。
トラップ部分全てにジャンプ命令が書かれているのか？
ジャンプ命令が無いのになぜ処理の順番が変わるのか考えろ。
>>105 >たとえば、システムコールがエラーを返して終了したらIOエクセプション、とかいう処理系は
>よくあるし、その実装にわざわざプロセッサ例外を起こしてそれをトラップして、なんて、
>普通はやらない。
疲れるなアホが多すぎて、じゃなぜ例外処理に処理が移動するんだ？
割り込み処理が発生するから例外処理に移動するんだろうが。
お前の書いたプログラムをアセンブラで見てみろよ。
「システムコールがエラー」で例外にジャンプする命令が書かれているか？
>>106 >ソフトウェア例外は、ただの分岐。全く割り込み関係ない。
アホｗ 自分が書いたプログラムも読めないのか分岐命令が書かれているか？
>>106 割り込みについてはそうなんだろうけど、ここで言ってる例外がなにを
さしてるみんなが話してるのかってことを度外視してまで続ける必要が
あるのかって部分で疑問だわ
setjmp/jongjmpで実装した例外処理とか知らないんだな、このバカは
>>107 >アホｗ 自分が書いたプログラムも読めないのか分岐命令が書かれているか？
書かれてるけど？何が言いたい？
まぁ、その付近にはシステムコールの割り込みが存在する事もあるけど
それはシステムコール用だし関係ない話。そもそもプロセスを跨いだ例外で無い限り
割り込み命令やスタブに出くわす事もない。だいたいWindowsじゃ割り込み命令(int)の
殆どはリングプロテクトの中じゃないと使えねぇしな。基本的に目にするのはスタブの割り込みだらけ。
ソースコード上の話してるだけだから、そういう事いってもわからないんだよ
>>107 は自分の書いたコードがどうコンパイルされてるか
アセンブラで確認することもしないんだろうなぁ。
>>112-115 まったくアセンブラも読めないのか、話にならない。
try-catchの間で、catchにジャンプするJxxxのジャンプ命令は書かれていないだろう。
どうやって例外処理が呼び出されているか考えろ。
>>115 読めよ。読める知識もないのに語ってんのかアホ。
>>118 人の書いたソースより自分の書いたプログラムのアセンブラを読めよ。
すぐに分かるだろ。 読めないのか？
あのな。try,catch,throwってのは、本当に
>>115 の呼び出しに置き換えられてるだけなの。解る？
アセンブリ化したコード読んでも、
>>115 のコードの呼び出しが書いてあるだけ。
わざわざアセンブリで読む意味がない。
>>120 まったく、なんでアセンブラを読まないのか。読めば解決するだろう。
じゃ、簡単な質問をする。
マルチタスクOSのメモリーは、OSやいろいろなプログラムが使っている。（これは理解できるだろう？）
自分の作ったプログラムでオブジェクトのメソッドを呼び出そうとする。
しかし、そのオブジェクトは不正な値が入っていたとする。（他のOSやプログラムが使っているアドレスを指している）
この時例外が発生するが、他のプログラムやOSの例外処理が動かなくて
自分のプログラムの例外処理が動くのは何故だ？
>あのな。try,catch,throwってのは、本当に
>>115 の呼び出しに置き換えられてるだけなの。解る？
その理屈だと、どうなる？
> しかし、そのオブジェクトは不正な値が入っていたとする。（他のOSやプログラムが使っているアドレスを指している）
> この時例外が発生するが、
例外が発生するかどうかは、OSやCPUのメモリ保護機能によって決まる。
発生するとは限らない。
馬鹿か。
> 他のプログラムやOSの例外処理が動かなくて
ＯＳやＣＰＵのメモリ保護機能によって、OSの例外処理が働く場合もある。
馬鹿か。
> 自分のプログラムの例外処理が動くのは何故だ？
馬鹿か。
> その理屈だと、どうなる？
>>115 のアセンブラの動きが答えだろ。
>>122 構造化例外の事を言いたいのか？
普通 _set_se_translator()を呼び出し、シグナルを言語仕様のthrow文に変換するコードを渡す。
基本的にOSからシグナルとして伝えられる例外と言語が持つ例外は別物。
暗黙だろうが明示的だろうが何らかのマッピングが必要になる。
まぁ、Javaなんかはシステムレベルの例外は、ランタイムでフックしてthrowに置き換えたり、
VMでリソース監視してVMがthrowしたりするけど、割り込みとは世界が別。
釣れたね。よかったね。
>>123 >例外が発生するかどうかは、OSやCPUのメモリ保護機能によって決まる。
>発生するとは限らない。
お前、自分で書いていて矛盾を感じないのか？
例外が発生するときはOSやCPUによって決まる書いているんだぞ。
意味がわからん。
>>126 中途半端に抜き出すな。
俺が言っているのは、
> しかし、そのオブジェクトは不正な値が入っていたとする。（他のOSやプログラムが使っているアドレスを指している）
> この時例外が発生するが、
つまり、他のＯＳやプログラムが使っているアドレスを差したときに例外が発生するかどうかの話をしている。これはOSやCPUによって違う。
たとえばulinuxやMS-DOSとかだと他のプログラムが使っているアドレスを差したとしても例外は発生しない。
なにも矛盾しているところはない。また中途半端に抜き出されたくないから、改行少なく書いてみたよｗ
お前ら誰がどの考えなんだ。
× １．例外はOS・CPUに依存する。
>>127 >つまり、他のＯＳやプログラムが使っているアドレスを差したときに例外が発生するかどうかの話をしている。これはOSやCPUによって違う。
>たとえばulinuxやMS-DOSとかだと他のプログラムが使っているアドレスを差したとしても例外は発生しない。
だから、お前はバカなの？
ulinuxやMS-DOSでは例外処理が発生しないのはOSによるものだろう。
>>129 お前は何が言いたいんだ？ ３と言う事じゃないのか？
お前は本当に意味が分からん、上から読んで整理してからこい。
わざとなのか知らないが、アドレス違反などの CPU 例外と、
ごっちゃまぜ以前に、
>>132 誰がごちゃ混ぜ話しているんだ？
まったく、例外はCPU、OSに依存しないと書いたかと思えば
今度はCPU、OSに依存すると書くしわけが分からん。
誰か俺の書いた
>>92 がどう間違っているのかを、はっきりかいてみろよ。
言っとくが一部の奴が言っている、一部言語に実装されている
擬似例外は、例外機構じゃない、擬似は擬似だ。
正式な例外みたいに言うのは間違っている。
> OSがマルチタスクだと理解できているのか？
>俺様定義を振り回したってだれもそんなもん知らんわ。
>>136 で、その俺様定義を「そーですね」って言ってあげれば立ち去ってくれるの？
すっごい粘着しそうなんですけど
ここまで粘着するからには
>>135 ,137
まったく自分だけ、かなり的外れ事を言っているのにきずかないのか？
俺以外の奴もこう言っているぞ。(
>>127 ,123)
>OSがマルチタスクだと理解していることがどう例外と関係するんだか。
>たとえばulinuxやMS-DOSとかだと他のプログラムが使っているアドレスを差したとしても例外は発生しない。(
>>127 )
Windows7とulinuxやMS-DOSの違いは？
あと、>ＯＳやＣＰＵのメモリ保護機能によって、OSの例外処理が働く場合もある。(
>>123 )
のメモリ保護機能ってどんな時に必要になる？
>> 技術者のくせに、CPUやOSの仕組みをしらない奴が多すぎ。
>それがどう例外と関係あるんだか。
>これはOSやCPUによって違う。(
>>127 )
お前が割り込むと、話がめちゃくちゃになる。 粘着するな。
> 自分だけ、かなり的外れ事を言っている
>>139 >それが目的ですからw
嘘つけ、本気で思っていたんだろうが。
それ言い訳、哀れすぎるぞ。
>>140 誤字ぐらいで揚げ足をとるか情けない。お前のも
>おまえもなんだけどなw
おまえ"も"って、自分が「的外れ」だと自覚はあるんだな。
>>134 > 誰か俺の書いた
>>92 がどう間違っているのかを、はっきりかいてみろよ。
「例外」の定義が一般的でない俺様定義になっているので、はっきりしません。
はっきりしたいのであれば、「例外」を「CPUの例外」「OSの例外」「言語の例外」あたりに
分類して書き直してください。
「言語の例外」の話でしょ、ここでは
「自分の関わった領域における例外」じゃね？
>>136 一部OSやCPUにしか実装されていないものを「一般的な例外」と主張するのは俺様定義でしかないなｗ
>>144 いちいち○○の例外とかうざい。
全部例外でいい。
それで勘違いするやつが馬鹿なのだ。
「一部OSやCPUにしか実装されていないものを「一般的な例外」と主張するのは俺様定義でしかないなｗ 」
ず〜〜〜〜〜〜〜〜〜と、つまらん話が続いて.......
でも、それでもこのスレを見てしまうのです。僕は病気でしょうか？
結局
>>92 は何が言いたかったんだ？
「お前等バカばっか!!俺天才!!悔しがれよクズがっ」とでも言って
自尊心を満たしたかっただけなのか？まぁ、今のところそうとしか思えない発言だらけだが。
それとも、万が一かもしれんが、もしかしたら、ひたすら割り込みに拘ることによって、
何かが劇的に改善する方法論を知ってるのか。もし、そうならダラダラ押し問答するより
その貴重な方法論をとっとと語ってほしいもんだ。
>>143 ,144
お前ら当然のように分類を決めているが、だれがその分類で正しいと言ったんだ？
「CPUの例外」「OSの例外」「言語の例外」の具体的な例外は？
この例外をその分類で表してくれ。足りなければ追加してくれ。
・徐算エラー
・配列境界違反
・無効命令
・スタック例外
・一般保護例外
お前らの言っている分類ってなんだ？
IOException も知らずにこれだけ大威張りしてきたとはなw
>>155 ・配列境界違反
・スタック例外
程度が知れるなw
>>155 そんな事はどうでもいいから、どういうメリットが
ある事を言いたいのか書けよ。
OSもCPUも理解してるはずのおまえが、分類できないわけがない。
>>155 0除算ひとつとってもプロセッサが例外を発生させることもあればソフトウェアが
検知して言語の例外を発生させることもあるわけで、要因に対して分類が１対１で
対応するわけでもない。
IA-32 の Divide Error をどれに分類するか、と具体的に言ってもらえれば、
それは「CPU例外」であるなどと分類を示すことができる。
「CPU例外」ってのは、バグ潰すのに便利だったんだけど
なんだ、また例外処理機構ｗのやつが出たのか。
やっぱりな、結局誰一人分類出来なかったな。
自分達が分類出来ないものを俺に分類して説明しろだと！
知識もない、いい加減な事しか言わない最低な奴らの集まりか。
>>156 IOExceptionは「CPUの例外」「OSの例外」「言語の例外」でどれだ？
>>158 >[割り込みだと両方セグメンテーション違反]
>・配列境界違反
>・スタック例外
>程度が知れるなw
俺には、お前の程度が良く分かるが。
OSレベルの知識しかないんだな。
>両方セグメンテーション違反
馬鹿か？詳細に分類したものを大雑把にいってどうする。
それなら全て例外と分類すればいいだろう。
>>162 なんでお前らが勝手に決めた分類を
俺が出来ないといけないんだ？ お前は頭おかしいだろう。
>>165 > 0除算ひとつとってもプロセッサが例外を発生させることもあればソフトウェアが
>検知して言語の例外を発生させることもある
よくそんな嘘を平気で書けるな。
”ソフトウェアが検知して”ってどんな仕組みで感知してるんだ？
具体的に説明してくれ。 まっ逃げると思うが。
>>173 > ”ソフトウェアが検知して”ってどんな仕組みで感知してるんだ？
仕組みというほどのこともない。
int f(int a, int b)
{
if (b == 0)
throw division_by_zero(a, b);
return a / b;
}
div(a, b){
もしかして、throwで例外を発生できることをしらない？
>>173 > やっぱりな、結局誰一人分類出来なかったな。
お前のお題が曖昧すぎるからだろ。 >165 の言うとおり。
> やっぱりな、結局誰一人分類出来なかったな。
>>174-176 それは単に例外を発生させているだけ。
それなら、チェックしないで>return a / b;
を実行した場合>return a / b;が検知場所か？
どこで検知して、どう例外処理を実行させているかを聞いているが。
割り込みスレでもCPU例外スレでも立てて、そっちでやってくれよ。
>>179 お前の中では「チェックする」と「検知する」が別物で、
「例外を発生させる」ことと「例外処理を実行させる」ことが異なるのか？
微妙すぎてわからんｗ
>>179 > どこで検知して
条件文で
> どう例外処理を実行させているかを聞いているが。
その言語に備わっている仕組みで。
CPUの割り込みも、OSの例外も出てくる幕はない。
まったく、じゃ簡単に書く。
int f(int a, int b)
{
if (b == 0)
throw division_by_zero(a, b);
return a / b;
}
と
int f(int a, int b)
{
return a / b;
}
の例外処理が実行される仕組みはどう違う？
アセンブラでデバッグしながな追いかければ
すぐわかるだろう。
>>184 お前は特によくアセンブラを追いかけろ。
>>185 int f(int a, int b)
{
return a / b;
}
もしかして、この場合も事前にゼロチェックしてるとおもってるのか？
例外を発生させることができるのはCPUだけ。
割り込みと例外の区別ぐらいつけろよｗ
>>185 b が 0 の場合、前者は C++ の規格に沿って例外処理が実行される。
同じ条件で、後者は未定義動作となるので何がどうなるとも言えない。
プログラムが止まるかもしれないし、 0 が返されるかもしれないし
1 が返されるかもしれないし、前者とまったく同じ動作になるかもしれない。
>>189 CPU の割り込みと例外の区別は CPU ごとに違うので、 CPU を
特定してからじゃないとなんとも言えない。たとえば ARM あたりだと
「割り込み⊂例外」という扱いだったりする。
割り込みに性質として、なるべく早く割り込み処理を
別に架空の話をしているんじゃなくて
ここ隔離スレだろw
隔離スレが隔離スレとして機能してるんだから、正常進行じゃないか。
>>192 あー。OSの設計とか次第だけど、割込みサービスルーチンではフラグ立てるか
カウンタをアップするだけで、必要な処理は別に起動したりとかするよね。
例えばWindowsの場合
>>195 > 例外を発生(throw)させると、WinAPIのRaiseExceptionが呼ばれ
> 割り込み処理(INT 2Eh)が走る。
それ、 VC++ で /EHa を指定したとき限定の話だよね？
http://msdn.microsoft.com/ja-jp/library/1deeycx5.aspx なんだ。古い VC++ しか知らなかったのか。そうかそうか。
割り込みはハードウェア的な話（ソフトウェア的に擬似的に発生するものを含める）
>>155 >>195 だからさぁ何が言いたいの？例外は割り込みだけで、ほかは擬似例外と呼べっつう
言葉遊びがしたいだけなの？
>>200 おおそうだね。一般保護例外はと無効命令は(SIGBUS)にも含まれるね。
抜けてたわ。
>>195 INT 2EHはカーネルモードへの移行。所謂スタブと同じ話で
例外とは関係ない。例外に限らずAPIを呼び出しカーネルモードに行く場合は呼び出される。
INT 00は割り込みハンドラを明示的に呼び出す場合に使うもので、除算時にソフトに明示的に
呼ばれる事は無い。除算時はCPUからINT 00に相当する割り込みが発生するだけ。
それがSIGFPE。
>>196 VC++なんて触ったこともない。
>それ、 VC++ で /EHa を指定したとき限定の話だよね？
/EHaを指定しない場合はアセンブラでどう動いているんだ？
>>198 >例外は基本的にそのプロセス限定で発生する。
それに対応している言語と例外は何だ？
その方がはるかに少数だ。ローカル言語を一般みたいに言うな。
>>199 俺は三つの分類を教えてくれとたのんだが？
それにそれは、UNIX系のシグナル分類にすぎないだろう。
俺の書いた割り込みはシグナルのもとになっているもの。
>>203 >INT 2EHはカーネルモードへの移行。所謂スタブと同じ話で
INT xxが割り込みを発生させる命令なんだが、意味がわからん。
>INT 00は割り込みハンドラを明示的に呼び出す場合に使うもので、除算時にソフトに明示的に
>呼ばれる事は無い。除算時はCPUからINT 00に相当する割り込みが発生するだけ。
書き方がわるかった、明示的には呼ばれていない。基点という意味で（INT 00h)と書いた。
まっこれは、CPUが発生される例外だと誰でも分かることだと思ったが。
>それがSIGFPE。
だから基点は割り込み番号：00hの処理で、それはUNIX系OSが勝手に対応付けしているシグナルにしかすぎない。
それはOSレベルの話だ。
えーと、このスレでは、
割込みと例外の区別が付いていない奴が騒いでるだけだろ。
>>205-206 わかった、俺も本当は例外が割り込みだから
例外はどうあるべきかを話したかったが
もう俺は書き込まない。
本質を無視して、目先の事だけを話してくれ。
「本質」という言葉を使う奴の99%は「俺様の定義する」である件
>>205 CPUの例外がJavaやC++の例外に変換されるみたいな言い方だけど、
実際はそんなことは稀なんじゃないの？
まったく関係ないことのほうが多いでしょ。
またお前かｗなんでこのスレでの例外は言語の機能だと何度言えば…
>>210 そこそこはあるよ。いちいち割り算の度にjzとかアセンブリ命令入れてたら非効率だからね。
>>199 に分類されてるものは、インタプリタやVMベースだと言語の例外機構に変換されてんじゃない？
まぁ、C++の場合はハードに依存するマッピングは自分でヤレがセオリーなんだろうけど。
おー…伸びてると思って覗いてみればすごい恥ずかしい奴がいるな…
>>214 読んだらわかったわ、誰が馬鹿かがｗ
９２は”馬の耳に念仏”のことわざを覚えたほうがいいぞｗ
家畜になにを期待しているんだｗ
>>214 でも、そのLinuxをC++で作るときの例外はどうするの？
たとえばIOの例外についてだけど
select の exception って、例外つーより OOB 食らった時じゃなかったっけ
92は例外がどう実装されてるかという話ばかりで、
>>92 それは例外処理の一種あって全てじゃないんだがｗ
キミらが好きなVBや昔のBASICにも例外処理があってだな、
ネットに転がってる例外処理の解説記事はだな、
例外なく間違いなく間違っているとう事実だ。ｗ
最後の「本質」が何かじゃんｗ
どーでもいいけど、例外を正しく使えっていう表現が変だろｗ
>>224 92は本質じゃなくて、実装について語りたがってたみたいだけどね。
>>223 >昔のBASICにも例外処理があって
On Errorのことか？ それは例外処理じゃないぞ
例外はfinally機能が大事だ
にわかなんで214の内容とか理解はしてないけれど
>>227 そういう視点でしか見れない人はマには向いてない。
実装こそ本質、と思ってる奴は結構いるよな
構造化想定外処理
>>94 の主張が嘘じゃないなら
>>121 とは別人なんだろうけど、
121にある過去スレの主張してた内容で見たら、結局は趣味の話。
俺は業務エラーで割り込みなんて気に食わないからよろしくないと思う。って感じの結論になるような。
まぁ、本質()の話題はもういいわな。その部分の理解は多くの場合必須じゃないし。
昨今の職業マのレベルで考えたら、勉強にかかる時間の割りにメリットはあまりないから、
興味がある人が自分で理解すればいいと思うレベルの話で、このスレの目的とは違うでそ。
正しく使えない人が多い一番の理由って、
>>229 > On Errorのことか？ それは例外処理じゃないぞ
> 例外はfinally機能が大事だ
catchじゃないのか？
finallyはなくてもcatchがあれば
finallyと同じことが実装可能だし。
>>229 いや例外処理だぞ。
try catch型例外機構じゃないだけで。
例外機構によって例外処理じゃないと言い始めたら
>>92 と同類。
>>214 それ、210と何か関係あるの？
CPUの例外がLinuxではシグナルに変換されてプロセスに通知される、って話だよね？
WindowsのSEHでもそうだけど、そこから先でさらに言語の例外に変換されることが
あるかどうかって話でしょ210は。
>>240 俺もfinallyがないのは例外じゃないと思うな
それならただのエラー処理だろう、名前もOn Errorだし
俺は
>>214 よんだから92は間違ってはいないと思っている。
92がいなくなるより、240みたいに決め付ける奴にいなくなってほしい。
>>243 > 俺は
>>214 よんだから92は間違ってはいないと思っている。
さすがにそれは無い。
LinuxのシグナルやWindowsのSEHなど（OSの例外）がCPUの例外を
プロセスに配信するだけのものがほとんどで関連性が強いのは
認めるが、このスレの主題である言語レベルの例外がそれらに
依存するなどということは無い。
もともと
>>92 の言う「例外」が「CPUの例外」や「OSの例外」を
指していて「言語の例外」を指していないのなら内容は間違って
いないと言えるかもしれないが、それをこのスレで偉そうに言うこと
自体が間違っている。
>>214 は"CPUの例外"の扱いについて書いてあるだけ。
何で、「CPU割り込み例外 = 例外」って書いてるやつの肯定になるんだよ。
CPU割り込み例外も例外の一種だから忘れるなというならわかるけど。
てか
>>243 =
>>92 なんじゃないか？
そうか？214を読むと他の奴らが言っていることが間違っていたと思えるが。
>>229 finally無くてもデストラクタついてりゃ済むじゃん。
デストラクタ無くても.net環境とかRubyとかデストラクタ相当の
ブロックスコープがあるし。
>>247 >>214 のどのあたりに感化されたの？
上のほうで割り込みベクタとか、スタブとか言って
>>92 と
応戦してる人はこの内容知ってて話してるようだけど。
>>247 おかしいな、俺には見えない何かを読んでいるようだ。
>>248 例外が発生したらオブジェクトを破棄するの？
>>252 別に破壊する必要ないけど？
それと、finallyは例外発生の有無に関係ないでしょ？
>>249 例外がCPUとOSに依存しているところ。
スタブはOSどまりでしょう。
>>254 ９２はスタブが間違っていると書いているか？
例外と、例外処理と、例外機構をごっちゃにして例外と呼ぶのをどうにかしてくれんか？
>>254 やっぱり
>>92 か。
>>214 は"CPUの例外"で
例外の全てについて書いてる訳じゃないって何度言われ手も
>>92 みたいに解らないようだ。
>>257 finallyと同じタイミング。
RAIIをはじめとして、オブジェクトの破棄だけに使うもんじゃない。
CPUで発生した割込みは
>>214 の機構を使って各プロセスに通知されるけど
それと言語における例外は別の話だからなぁ。
だから、CPUレベルで0割による割込みが発生して、各プロセスに通知された
としても、それがC++の例外としてcatchできるわけではない。
(catchできる環境もあるだろうけど)
>>92 は言語における例外を擬似例外とか言って相手にしたくなさそうだったけど、
そもそもこのスレは言語における例外をどう使うかを議論してきたわけで。
>>229 はfinallyを何に使う気なんだろ・・・。
finallyはガベージコレクタというか
例外と話ずれるけど、なんでJavaのfinallyってtryが必要なんだろ？
>>263 お前はfinallyブロックでなにをするつもりなんだ？
>>259 finallyとデストラクタが別の処理だったら？
そもそもそれなら何でfinallyがあるの？
これ ； デリミタっていうんだけどさ、これをつけなきゃエラーになるような
天使◆uZeeeは新しいバリエーション作ったのか？ｗ
というかfinallyの意味わかってないだろ。
>>265 Disposableな一時オブジェクトつくるのが面倒だからだろ。
Javaに限れば、ブロックスコープでの処理の強制実行がないから。
>>258 >例外の全てについて書いてる訳じゃない
例えば？
>>264 ファイルのcloseとか。
ファイル閉じるのに別にtryブロックは要らんよな。
>>268 あれ？tryブロック入らなかったら、finally実行されないんだっけ？
>>260 >CPUレベルで0割による割込みが発生して、各プロセスに通知された
>としても、それがC++の例外としてcatchできるわけではない。
出来ない環境ってなに？ 具体的に。
finallyを使わない人はリソース保護どうしているの？
>>270 FORTRAN時代からException handlingと呼ばれた処理。
損壊データに対する例外処理とかな。
>>274 デストラクタ、disposeとusing。
>>274 あとOSとリソース管理ライブラリへの委託か。
>>270 FORTRANの例外はCPUとまったく関係なく動くの？
>>276 ,277
ファイルクローズやDBクローズもそれでやるのか？
だからなんで「まったく」関係なく、が出てくるんだよｗ
>>281 そういう意味じゃなく、CPUの割り込み関係なく例外が動くの？
>>282 そもそも、CPUの割り込みと関係ない例外を
話すのがこのスレのテーマだよ。
>>273 0 割が C++ の例外として catch できることのほうが稀なわけだが。
できない環境を具体的に挙げろと言われれば、 VC++ で /EHs を
指定すればそうなる。
>>286 上の方に書いてあるので読み直してください。
つか0除算なんて例外機構で処理するハメになっても何もそのプロセス単体じゃ出来んと思うけど。
本来0除算が発生しないようにプログラムを組むべきだし。
>>278 だから例外機構と例外処理は違うと何度言ったら・・・。
漏れまくりだけど、整理してみた。
>>287 お前は例外処理でなにをしようと考えてるんだ？
0除算が発生したらやることはない？素人か？
実際に動くアプリを作ったことがないのか？
やるかやらないかは、アプリの仕様次第だが、
0除算が発生したときにやることはたくさんある。
・0除算が発生したことを画面に表示する。
・0除算が発生したことをログに記録する。
・スタックトレースを表示する。
・0除算が発生した処理のみを中断させ、正常なコマンド入力状態戻す。
やることはたくさんあるだろ。
このスレにおける例外というのは、
>>291 さてあなたの発見したゼロ除算はどこで発生したんでしょうね。
try
{
Example object = new Example();
object.Method(10,20,30);
}
catch(・・・)
{
・・・
}
こんな感じで入力だけに閉じてるなら問題ないし、
>>291 の対処法をとるのは正解だよ。
でも1つでも出力があったり、ゼロ除算を発生させる可能性のある式が露出してたら、
例外処理すら失敗する可能性がある。そもそも、ゼロ除算が発生する箇所が
最初から解ってるなら、ゼロ除算を発生させないように書けるはずだしね。
>>294 > さてあなたの発見したゼロ除算はどこで発生したんでしょうね。
tryの中のどこか。
どこで発生したかは、例外オブジェクトが持っている。
例外オブジェクトに聞けば、発生した箇所を
スタックトレースとして取得できる。
常識だと思うんだが、こんなことも知らないの？
>>291 大半の例外機構にリトライ機能がないのはなぜか知ってる？
例外が起こり得た範囲の値は全て信用できないからなんだってさ。
RuntimeErrorの類がチェック例外になっていないのはコレがひとつの理由だって。
もうひとつは、プログラマの意図を把握する手段が無いからだって。
>294
>>296 > 大半の例外機構にリトライ機能がないのはなぜか知ってる？
ん？
例外機能とリトライ機能は全くの別物だからだよ。
お前が言ってるのは、「関数にリトライ機能がないのはなぜか？」のような
まったく意味不明なことを言っている。
リトライは例外機能とは別に追加するするもの。
どんな箇所にでもリトライ機能は組み込める。
そして組み込むかどうかはアプリの仕様できまる。
>>295 0除算が影響するデータはtryブロックから絶対出てこないんだ。へぇ〜。
じゃあその結果はどこで受け取る予定だったんだろうね。
スタックトレースをそのプログラムで解析して、ゼロ除算になった変数を特定しデータを復帰するの？
俺が場所が解るってのはそういう事なんだけど。データ破損についていってるのにスタックトレースとか入門者かよ。
> 例外が起こり得た範囲の値は全て信用できないからなんだってさ。
>>295 お前、0除算したときにどうするかは
一つに決まると思ってないか？
0除算したら、その値は0として扱うとか考えてるでしょ？
>>298 文脈を読め。もしゼロ除算で他に影響が無いならリトライも可能になるはずだろうがって言ってんだろ。
ハゲを初め言語制作者はそれを無理だといってんの。
>>300 今例外全般の話をしてないよ。
この1つのレスに答えてるだけ。例外自体は原因を特定できるけどそんな問題じゃない。
> 291 名前：仕様書無しさん [sage]： 2011/07/03(日) 21:11:02.26
>
>>287 > お前は例外処理でなにをしようと考えてるんだ？
> 0除算が発生したらやることはない？素人か？
> 実際に動くアプリを作ったことがないのか？
>
>
> やるかやらないかは、アプリの仕様次第だが、
> 0除算が発生したときにやることはたくさんある。
>
> ・0除算が発生したことを画面に表示する。
> ・0除算が発生したことをログに記録する。
> ・スタックトレースを表示する。
> ・0除算が発生した処理のみを中断させ、正常なコマンド入力状態戻す。
>
> やることはたくさんあるだろ。
あー、こんな話をきたことがあるわ。
>>297 にも同じ話な。割り込みの話じゃない。
>>291 のレスに閉じた話。
めんどくせぇなぁ。
このコードでゼロ除算が発生した場合、
このクラスのオブジェクトが健全だと言えるのか？
もちろんこのコード自体に問題があるが、
具体的に回避策を上げてみろよ。
class Sample implments Interface
{
public void setValue(int value){・・・}
public int getValue(){・・・}
public void exampleMethod()
{
try
{
Example example = new Example();
example.Method(this);
}
catch(・・・ゼロ除算キャッチ・・・)
{
>>303 }
}
}
見づらいんで直した。
class Sample implments Interface
{
public void setValue(int value){・・・}
public int getValue(){・・・}
public void exampleMethod()
{
try
{
Example example = new Example();
example.Method(this);
}
catch(・・・ゼロ除算キャッチ・・・)
{
>>303 }
}
}
この馬鹿相手にするのは疲れたから
でゼロ除算箇所を確実に特定し復帰する方法はある。
try
{
y /= x;
}
catch(・・・ゼロ除算キャッチ・・・)
{
>>303 }
ただし、この場合割り算一回に1個try catchが必要になる。
加えて、そこまで例外箇所を絞り込んでんなら初めからゼロ除算しないように修正しとくのが普通。
>>307 バグがあるコードが健全かどうか聞かれても困る。
例外が起きたとき、オブジェクトの状態が異常になることがあるが
それを回復させるのがcatchやfinallyの役割。
catchやfinallyの中で不安定になっていても、
それを抜けるときに回復させていれば問題ない。
回復させるというのは、処理を続行するということはではない。
不安定（不定）である部分をなくすということ。
エラーとして親関数に返すことも回復の一つ。
これぐらいヒントを与えれば、自分で気づけるだろ？
>>309 だから割り込みの話はしてないんだっつのアホ。
ゼロ除算があっても
>>303 の対処ができるとかいたんだろ。
それが無理だっつってんの。それが分かりゃ終わりだ終わり。
割込なんざどうでもいい。
>>310 >>312 自分で、出来ることを
>>310 で
証明しているようにしか見えんのだがｗ
>>311 具体的にコードを見せろ。素人じゃないんだろ。経験者なんだろ。さくっとコード出せるだろうが。
まさか、ゼロ除算に対するコード書いたこともないのに空論で語ってるだけのシステム土方か？
パッケージ開発した事があったりすれば解るだろ？
>>312 結局さ、お前0除算を例外で処理することを
毛嫌いしているだけじゃね？
どうせ0除算するコードをなくすと言っても
計算する前に0かどうかチェックするだけだろ？
めんどくさいよね。特に式が長くなった時とかさ。
x = a + b / foo() - c;
とかさ。if使ったら面倒になるでしょ。
でお前はifしか使えないから、例外なんか食わず嫌いで使ってないだけ。
>>315 まず、お前が先に
ゼロ除算に対する具体的なコードを見せろって
誰かに言われなかった？
>>313 最初から、ゼロにならないことを保証したオブジェクトとれば済む話。
int Method(int x,NoZerroObject object)
{
return x /= object.getValue();
}
>>314 >そこまで例外箇所を絞り込んでんなら初めからゼロ除算しないように修正しとくのが普通。
おわかり？
>>318 馬鹿だｗｗｗ
じゃあその変数に0を入れようとしたところで
例外が発生するだけじゃないかｗ
>>317 問題があることを書いただろうが。
なんで問題があるっつってんのに自分で、問題が無いコードを提示すんだよ分裂症か俺は。
>>320 お前が示すのは、例外を使わないで
0除算を防ぐコードだよ。
>>318 ゼロにならないことを保証した変数を使えば
済む話だな。
>>310 の例だと、
y /= NoZerroX ;
>>319 ゼロ除算は発生しないよな？
そもそもNoZeroObjectで例外が発せいた場合は、
NoZeroObjectにゼロが入力されたことは明らかだ。
最入力なり何らりさせても他に影響が無い。
問題の発生箇所が初めから特定可能なのと、
>>308 のように不特定なのでは全然問題が違うぐらい解るだろ。
>>318 があまりにも痛すぎるコードな県についてｗ
>>321 例外を使うなとは言っていない。"ゼロ除算例外は対応できない"といってんの？はよコード出せや。
>>322 そうだよ。そのとおり。
>>324 が素晴らしいコードを見せてくれと聞いて。
>>325 はちょっと間違えた。
>>294 の場合以外は"ゼロ除算例外は対応できない"だ。
誤解されてる気がするが、NoZeroObjectって名前のクラスを作るわけじゃないからな。
>>323 > ゼロ除算は発生しないよな？
つか、本末転倒だろ。
ゼロ除算エラーが発生しない代わりに
ゼロ代入エラーに変っただけじゃん。
割り算するたびに変数の値を、そのNoZeroObjectとやらに
一回代入して0かどうかの実行時チェックをするのか？
毎回毎回。ifでやる面倒さをなにも解決していない。
頭悪いよ。
もしゼロ代入エラーにならないのなら、
xが0になることもないわけで、
そもそもy/=xで例外が発生することもない。
>>328 得られる値がゼロにならなければ、例外も発生しませんよ？
例外を使ったコードでも、
問題は解決ですよね。
このスレ、Javaでしか考えられないヤツが異様に多い割に、
で0除算にならないことをを保証する方法はないんだよね。
>>331 ネットでググッても書いてないようなことはわからないよ（笑）
0除算エラーがなぜ実行時エラーなのかというと
>>330 そうだよそのとおりだよ。
void Parse(String[] valueBlock)
{
try
{
tihs.polygon.push(new Point( valueBlock[0]., valueBlock[1] ) );
}
catch(・・・エラー・・・)
{
//体積が0になったので入力エラー
}
}
入力時点で0に対処してりゃどこに渡ろうが0になることはない。
まぁ、計算結果0になるのであればそこでの対処はいるが、
0除算エラー例外に比べれば範囲ははるかに特定しやすいし、
他へのの影響もない。
>>332 具体的なコードを書けって。
>>334 >>303 を読んだ上でいってるの？0除算を防げるかどうかがメインのテーマじゃない。
>>303 のような対処法無理だし、最初からゼロ除算を防ぐ方法をこうじるしか無いっていう話なんだよ。
>>336 少しお前は話をまとめろ。
１．何のために
２．どうやって防ぐか
たった二つだ。
その両方を答えよ。
>>337 1.
>>303 のアホな対応により
>>308 のようなデータ破壊の連鎖を防ぐため
2.
>>335 のように意味論理的に0の発生を特定でき、他に影響が波及しないオブジェクトを使用する。
>>338 >>303 ずっとレス番間違えてたわ
>>303 は
>>291 の事な。 引用してるから解るかもしれないけど。
１．0除算の結果、その時の変数の値を信用することはできない。
そもそも勘違いは０除算をしたときに
本質を考えないまま、0除算さえ防げれば
>>339 ならんよ。だってゼロ除算と違って発生場所が圧倒的に少ないんだもん。
try
{
frameVector.sub(sourceVector);
return new NoZeroVector( frameVector );
}
catch(・・・禁止されたゼロベクタ・・・)
{
//図形が成立していないエラー
}
意味論理で考えれば、ゼロ除算の割る値になれる値が0になる箇所なんて
どう考えても最初から成立しない値になる。
>>344 言葉が変だった。
>意味論理で考えれば、ゼロ除算の割る値になれる値が0になる箇所なんて
>どう考えても最初から成立しない値になる。
どう考えても最初から成立しない値が発生してるのですぐ解る。
>>344 圧倒的に少ないから、ならないというのは
どう考えても論理的ではない。
それにお前初期値の話しかしてないよな？
0になるのは、なにも関数の引数にした時だけじゃない。
長い計算の結果の途中で0になることだってある。
それをどうやって防ぐんだ？
もしかしてすべての変数を0代入不可オブジェクトにするのか。
四則演算し全て使えなくなりそうだな。
なんか俺俺ライブラリ作ってオナニーしているのが目に浮かぶｗ
>>342 >そもそも勘違いは０除算をしたときに
>オブジェクトが健全にならないと勘違いしていることだよ。
じゃ
>>308 を健全な形に書きなおしてくれ。
コードにすらおこせん御託はいらんから。
>>345 最初から成立しない値が入っているのを防ぎたいののなら、
ifつかって変数の中身をチェックすればいいだけだよ。
>>347 > じゃ
>>308 を健全な形に書きなおしてくれ。
それは不可能。ゼロ代入エラーにしても不可能なことを
解決することは不可能。
まずお前が、どんな状態でも完璧に健全になるというコードを書け。
短い例だけではなく、複雑な例でも対応できるやつをだ。
>>346 意味論理的にって文字を読んだか？
体積1で高さが0の立方体とか存在すんのか？
机上の空論で語るなよ。具体的な例をあげてみろ。
NoZeroなんたらを使ったところで、
>>349 何行書かせる気だ、一行も書いてないくせに人にかけというな。
しかも、どんな場合でもというなら
>>294 に書いた。
>>351 入力地点に図形が不正で、座標がオカシイって伝えるに決まってんだろ。
その時点で、このオブジェクト自体は破棄されプログラム上に不正なオブジェクトは存在しなくなるわ。
>>350 だから、お前は初期値の話しかしてないと言うんだよ。
体積を入力してください？
高さを入力してください？
if(高さが==0){エラー}
こういう単純な話しかしてないだろ？
こんなふうに関数の最初で0かどうかチェックできるような例なら簡単だろうさ。
>>353 > 入力地点に図形が不正で、座標がオカシイって伝えるに決まってんだろ。
入力時点で、おかしいかどうか分からない場合だってあるだろ。
やっぱり初期値チェックだけで済む話しかしてないわお前。
つでにゼロ除算エラーが入力地点まで上がっていった場合は、
>>351 でNoZeroなんたらを使っていても
オブジェクトが不健全になる例は示した。
話はこれで終わったはずだが。
それから、0除算をしたとしても
それまでの結果をローカル変数に入れておけば
オブジェクトは健全なままになる。
結局、例外が起きたとき健全かどうかは
例外の種類を変更しただけで解決する問題ではなく
その時のロジックで決まるんだよ。
>>354 >>355 計算結果の場合は
>>344 に書いたよな。見たのかよ。
>>356 >>357 だからそのオブジェクトは破壊されるんだって。
なんで全体で捉えられないの？
try
{
Example example = new Example();
example.
>>351 の処理();
}
catch(略)
{
略
}
>>360 お前、間抜けかｗ
>>351 はお前が言うNoZeroなんたらを使った場合だぞ。
0除算例外を0代入例外にしたところで
壊れるって最初から言ってるだろｗ
>>359 int i;
try
{
for(i=0;i<frameVector[i].length;++i) frameVector[i].sub(sourceVector);
{
catch(・・・禁止されたゼロベクタ・・・)
{
//図形が成立しんていない i番目の座標が異常
}
>>362 とんちかよｗ
全部一行につなげて書けば、
どこの行かはすぐに分かりますってかｗｗｗｗ
コード書き換えて、エラーの箇所を示すための変数を作って
>>361 そうですね。但し影響範囲は特定できる。
その情報はNoZeroが出した例外に入っているからね。
引数を書き忘れてたが、この引数自体は破損していないことが確定できる。
もちろんsource自体は、Exampleのオブジェクトに大しては毒だが、
新たなエラーの引き金にはならないことは解る。
例えばエラーメッセージとしてsourceの中身を参照する分には問題ない。
Example example = new Example();
example.
>>351 の処理(source);
>>363-
>>364 元がおかしいだろうが。なんで名前の一ベクトルが大量にあるんだよ。
その場合配列しか無いだろ。
仮に名前のついた配列が2本あったらその1個1個でtry-catch書くわ。
> その情報はNoZeroが出した例外に入っているからね。
>>365 それがやりたいんならやればいいんじゃない？
意味合いが解ってて絶対ゼロが来ないと解っててもやってりゃいいんじゃない？
話をまとめるとだな。
>>367 具体的にどうぞ。
例えば、exampleが図形で「図形で異常が起きたという例外」が発生すれば、
source側は無事だと解る。じゃゼロ除算の例外でsourceが無事であることをどうやって知るのかな？
>>368 で、計算結果が0にならないということは
どうやって保証するんだ？
>>370 お前こそ具体的に答えろよ。
exampleが図形で「図形で異常が起きたという例外」が発生すれば、
source側は無事だとなぜ言い切れる？
>>369 まとめるのはいいが、元々は
>>291 は無理って話だったんだけどね。
>>372 「図形が異常で起きたという例外」の仕様がそういう例外だからだ。
IOExceptionがオーバーランが原因で発生することがあるか？
問題の範囲は特定できるんだぞ。
逆にゼロ除算。まぁ別にnullぽでもいいがそっちにそういう仕様はあるか？
>>373 ん？
0除算が発生したときに、
「0除算が発生しました」とダイアログボックスを表示することは可能だし、
どうようにそれをファイルに保存すればログに記録できるし。
スタックトレースなら普通に出力されるし、
GUIアプリ、ウェブアプリで、0除算が発生しましたとでるが
アプリ自体は終了しないことはたくさんあると思うが？
>>375 さんざん書いたよな。
>>294 >でも1つでも出力があったり、ゼロ除算を発生させる可能性のある式が露出してたら、
>例外処理すら失敗する可能性がある。そもそも、ゼロ除算が発生する箇所が
>最初から解ってるなら、ゼロ除算を発生させないように書けるはずだしね。
とか
>>308 とかさぁ。
>>376 例外自体に、オブジェクトの状態を変更しませんと
定義することはできんぞ。
同じ例外を出したとしても、その例外を発生するまでのロジックで
オブジェクトの状態を壊すかどうかが決まるんだからな。
「このメソッドで例外が起きてもオブジェクトの状態を変えません」と書かれていれば、
0除算例外がでたとしても、ほかの例外と同じく、状態を変えないという仕様だ。
>>377 スタックトレースをユーザーに見せるの？
あと、sourceの健全性は解らないだろそれじゃ。
sourceってのは
>>366 で出てくる引数のことな。
>>378 それのどこが、
「0除算時にダイアログボックスを表示することが不可能（等）」という
理由になると言うんだ？
>>388 > スタックトレースをユーザーに見せるの？
お前は実務経験無いのか？
スタックトレースをユーザーに見せるかどうかは、
アプリの仕様しだいだろ。
ちなみに実際に見せてるアプリは多いぞ。
-vオプションとか-dオプション付けたら表示するものもある。
>>380 366の引数？
それ、例外が発生したら壊れるよ。
壊れるようなコードを書いているからね。
で？
繰り返すが、例外の種類で
やっぱり0除算をCPU例外の0除算と
え？ 0除算が発生したら
>>381 んな事いってないだろ。「0除算が発生しました」という無能の極みみたいなメッセージ出すだけならもんだいねぇよ。
それより、健全なオブジェクトと壊れたオブジェクトを判別できない事。なんかい同じ事を書かせんだよ。
問題が発生したオブジェクトが特定できないと、どれが壊れてるか解らないまま処理を継続する事になり、
多少処理する例外処理も失敗するわ、健全なデータも判別できないから、健全なデータも破棄する事になるわ問題が発生するから処理継続は無理と書いてる。
>>382 デバッグ機能はともかく、エラーメッセージ替わりにユーザーに見せるのは最悪だけどな。
>>384 そうかもね。じゃ変更する場合はどうなるんだい？
>>385 ゼロ除算やら割り込みが問題じゃないんだよ。
10箇所で発生する例外をまとめて捕まえて、
10箇所のうちどれが壊れてんのか、それがどこに影響してんのか
特定できない状態で例外処理やってるってのがおかしいって話。
>>386 >>308 じゃ極論しよう。
>>389 ん？
>>308 がどうかしたのか？
ロジックによってオブジェクトが壊れるかどうかが決まる
0除算例外にだけ特別なことは何も無い。
そうだよな？
>>391 そうだよ。
・壊れたオブジェクト
・無事なオブジェクト
この2種類を判断できない状況で処理を行うな。って話だよ。
>>387 例外発生時に発生する副作用が特定できるように、
例外安全性を意識した設計と文書化を行いましょう。
それができてない前提であれば、あなたの言うとおりかもしれません。
でもそれは例外という機能による不可避な問題ではないのです。
>>391 あ〜ロジックによってってのはちょっと誤解があるな。
ロジックによって壊れないことが保証されている場合は、そのとおり。
ロジックによって壊れるかもしれない場合は、例外で判断するしか無い。
もう一点、この問題はエラー通知方法に例外を使った場合にのみ発生するものでもありません。
>>390 当たり前ｗ
それをお前は例外の種類で区別できると
言っていた大馬鹿者ってだけだ。
ロジックの途中で例外が発生した時、オブジェクトが壊れるかどうかは
ロジックの内容できまるのであって、例外で決まることはない。
たとえ0除算が起こったとしても、それまでの処理の結果を
ローカル変数を使うなどしてオブジェクトを変化させていなければ
オブジェクトが壊れることはない。
また、他のどの例外が発生したとしても、その例外が発生するまでの間で
オブジェクトの状態を変化させていれば、オブジェクトは壊れる。
たとえば、NoZeroObjectに0を代入する前に、オブジェクトの状態を変化させていれば
当然0を代入して例外が発生すると、オブジェクトの状態は壊れている。
> ロジックによって壊れるかもしれない場合は、例外で判断するしか無い。
やっと話が集約してきたな。
まとめるとこうか。
>>398 そうだな。もともと
>>291 がおかしいって話でボヤけてたが本体がみえてきたな。
> ・ロジックによって壊れるかもしれない場合は、無事かどうかを例外で判断するしか無い。
>>400 0除算に限らず、任意の例外(0除算含む)が発生したときに
>>397 例外はランダムじゃないから判断できるだろ。
void func(Source source)
{
try
{
int value = 0;
・・・処理・・・
source.add(value);//add内で例外が発生した場合、sourceは破損。
}
catch(・・・funcが所属するオブジェクトで発生した例外・・・)
{
//・・・funcが所属するオブジェクトが壊れた例外を出す。
}
}
受け取る側は、funcが所属するオブジェクトが壊れた例外かそうでないかで、
sourceがまだ健全であることを判断できる。もちろんaddが行われてないんで
その分結果が違うが。source自体に変化が無いことは解れば十分。
結局、
>>291 に難癖つけたやつが
的はずれなこと繰り返してただけじゃねーかｗ
>>402 それを全ての割り算に書くならねぇ・・。っていう話でNoZeroとか出てきたんだけど今更もどるのか、あの話に。
>>404 >>405 そうだね。全ての割り算に
>>291 を書くなら的外れだろうね。以下略。
>>407 ・ロジックによって壊れないことが保証されている場合は、そのとおり。
・ロジックによって壊れるかもしれない場合は、無事かどうかを例外で判断するしか無い。
>>406 > それを全ての割り算に書くならねぇ・・。
何のために？
>>409 だから、例外を見ただけでオブジェクトが壊れているかどうかを判断することは
不可能だってばｗ
どういう理屈で判断できるのか
説明してみ。
どうせこのロジック（メソッド）では壊れないと
書いてあるからが答えだろ。
ほら例外の種類ではない。
一体なんのためにすべての割り算に例外を書くのか理解出来ない。
>>410 >>412 ほい
>>399 >>411 ほい
>>404 「funcが所属するオブジェクトが壊れた例外」がfuncが所属する
オブジェクトが壊れた時にしか出ないことを仕様として決めてる限り明らかじゃん。
>>413 さっきから論破されたリンクばっかり出すなよｗ
> 「funcが所属するオブジェクトが壊れた例外」がfuncが所属する
> 例外をキャッチするだけの人だと、自分で詳しい例外を作って投げるという発想がないのかな？
>>411 そういや、そうだよ。メソッドの仕様に書いてあるからだよ。うんそのとおり。
・ロジックによって壊れるかもしれない場合は、無事かどうかを例外で判断するしか無い
がよく解らないメソッドから出てきても例外だけで判断できると解釈されたんなら誤解だ。
どのオブジェクトが壊れたとき、どの例外が発生するかはメソッドの仕様で決まってる。
だから、どのオブジェクトが壊れたか判断できると書いたほうがただしかったか。
俺は、筋の通った間違いの指摘は、認めてるつもりだが、ここぞと同じ事を
>>419 また自分の言葉を訂正したな。
結局お前が言っていることは何一つ
正しくなかったってことじゃねーかｗ
>>291 は正しかったってことか。
結局否定できなかったもんな。
>>422 訂正ねぇ。したよ。言い回しが違うだけでいってることは他の人と同じよだったから。
内容は
>>404 に書いたものと変わってないけど。
>>423 >>291 を全ての割り算に書からないなら
・壊れたオブジェクト
・無事なオブジェクト
この2種類を判断できない状況で処理を行うな。
が守れないよねって話を刻々と続けてきたと思うけど。
>>424 誤解をまた生みそうなんで訂正。
>>423 ・壊れたオブジェクト
・無事なオブジェクト
この2種類を判断できない状況で処理を行うな。
を守るには、
>>291 の方法だとtry-catchを全ての割り算に書かなきゃならないよね。
>>424 だからすべての割り算に書く必要はないんだってばｗ
例外処理はひとつにまとめられるの。
そして一つにまとめたところで、
ローカル変数に途中の処理結果を入れていれば
どこで例外が起きても、オブジェクトのの完全性は保たれるんだってば。
> を守るには、
>>291 の方法だとtry-catchを全ての割り算に書かなきゃならないよね。
なんで？
>>426 double scale = 0;
try
{
point.x /= scale;
point.y /= scale;
}
catch(・・・)
{
//scaleは不正
}
こういうのだったら当然割り算度に書く必要ない。
そういう話じゃないわなぁ。
try
{
int a,b;
a /= scale;
b /= scale;
this.a = a;
this.b = b;
}
catch(・・・)
{
//scaleは不正
}
こういう話なんだろうか。
thisの健全性が高くなるのはたしかだね。
いつまで続けてんだよ
>>92 はだいぶ以前からスレに沸く見当違いさんだから触るな
初レスとか嘘ついたり、もう来ない宣言のあと当たり前に自演したりとか、相手するだけ無駄だぞ
>>428 はぁ・・・。確かというか、例外が発生する可能性があるコードの前、
つまり関数の最初に引数をチェックして、それでOKならそれでいい。
だが引数チェックしたところで、すべての例外が起きなくなるわけじゃない。
むしろゼロ除算例外のように、引数チェックで例外が発生しないことを保証できることなんてまれ。
（つーか、ゼロ除算例外だって計算結果が0になってその値で割れば発生するから引数をチェックしたところで完璧ではない）
だから例外を発生させないようにするという考えは現実的ではなく、コード上のどの箇所で例外が起きても、
問題ない作りにする。これは0除算の限った話ではない。すべての箇所で同じような作りにする。
で、コード上のどこで例外が発生したとしても、問題ない作りにするには、
オブジェクトの状態を変えるコードは処理のなるべく後のほうでやって
途中はローカル変数のみを使ってコードを書く。
これはある程度実戦経験積んだ人にとっては当たり前に書くコードなんだが・・・。
ため息しか出ないよ。こんな初歩中の初歩をしらんやつだったとはな。
>>429 ゼロ除算やら割り込みが問題じゃなくなってるんだけどOkey?
ついさっきまで、ゼロ除算だと・・・って
>>430 こっちの要点は健全なオブジェクトと壊れたオブジェクトを判別し、
安全な状態で処理または、例外処理を継続すること。
まぁ、そもそも保全に対する方向性が違うんだろうね。
俺だって"割り算毎に例外チェック"すんのは馬鹿げてると思う。
でも
>>291 の方法だとそうは行かない。だから、それを避ける手段を
NoZeroの流れと、メソッドの仕様と例外の区別を利用する流れで提示した。
まぁ、方向性が違うから他の人には納得する点は一切なかったらしい。
10個20個例外が発生する箇所をまとめてキャッチしたらどれが壊れてるのか解からん。
根本的にはゼロ除算は関係ないし、Nullポだろうが、
SQLExceptionだろうが、IOExceptionだろうが同じ話だったんだけどな。
それじゃ消えるよ。めんどうだから。
>>433 > でも
>>291 の方法だとそうは行かない。だから、それを避ける手段を
> NoZeroの流れと、メソッドの仕様と例外の区別を利用する流れで提示した。
それじゃ無理。あくまで関数の最初でチェックできることにしか対応できない。
途中の計算で値が0になったらどうする？
どっちみち処理の途中で例外が発生することになる。
処理の途中で例外が発生することを防ぐことは不可能なのだから、
その場合でもオブジェクトが壊れないようにするには処理の途中でオブジェクトの状態を
変更しないようにローカル変数を使う。普通はそのようにコードを書く。
どうしてもそれが不可能な場合のみ、catchかfinallyで復帰処理を書く。
それがコーディングのセオリーだ。
> 10個20個例外が発生する箇所をまとめてキャッチしたらどれが壊れてるのか解からん。
わかる。例外オブジェクトにどこが壊れているか情報が格納されている。
どうしてもわからないのなら、自分で情報を追加すればいいだけの話。
結局お前は、技術力不足により意味のない俺俺解決方法を思いつき
それを偉そうに語っていただけ。お前の保全に対する方向性が斜め上を向いていただけの話。
実戦経験がないから、変な方法を思いつく。頭が良いのではなく頭が悪い証拠だ。
> それじゃ消えるよ。めんどうだから。
できれば今後一切出てくるな。初心者の相手は面倒だ。
>>434 >>219 さんお疲れ様。あんたもお帰り。
>>435 さっさと消えろよ。自分で言ったんだろ。
>>436 お前の敵はひとりかよw
>>434 も
>>433 もどっちも実践あるとは思えんから言っただけだ。
両方帰れ。
>>437 お前が一番実践なさそうだな。
何一つまともなことを言ってなさそうだからな。
お前の発言はどれかね？ｗ
>>438 おれこの口論にゃ参加してないよ。
話を聞き出すならともかく、自分の意見を相手に
押し付けあうなんてバカバカしいじゃん。
社会人なら解るはずだけど？
だから、どっちも実践あるとは思えないって書いたの。
> おれこの口論にゃ参加してないよ。
最初から例外でないようにかけばいいじゃんバカだな
適度な阿呆が独自論展開しはじめると盛り上がるけどねえ
例外理解してない人は、例外意外もわりと理解してないな
いい加減な集約例外とか、統一性のないログ処理とか
例外とかあんま関係ないけど、
もういちどやりなおしてください。つづくばあいはれんらくしてください。的な。
もう一度やり直しては不味くね？
仕様上予期してないわけだし、システムがエラーなんだからそのままでいいだろ
>>454 テスト漏れな異常引数とか配列のコレクションのオーバーランとか
すぐバグだと解るけど、対策なんてできるか?
ひとついわせてもらうと
kardとか書いちゃうヤツが、ずいぶんよその国に詳しいんだな。
触るときは本当に反応してあげる価値がある相手かを考えてから触ろう
それは解るんだが問題はどう通知するかなんだよ。
>>459 このバグを報告したら1万円あげますって書けばいい。
>>459 例えば給与会計のシステムで
誰かの勤務時間登録でエラーが出たらガン無視してExcelで手打ちする
みたいなオモシロイことをしやがる会社はある。
ユーザーもアホではないんで、なんとか凌ぐもんだよ。
あまり神経質になりすぎてもこっちが辛いだけでな。
まぁ今のところは本当の意味での例外、例を挙げれば
ソフトウェア以外の部分で生じたトラブル(LANケーブル断線とか、ODBCとかJDBCの設定ミス)
は例外扱いくらいだ。
DBのコネクション張れないとか、あるはずのJPGファイル読めない(ユーザーがファイルいじってね？)とか、そんなの。
Excelで手打ちして
>>461 お前みたいなゴミがいるから腐敗していくんだろうな
身の程を知れクソゴミ
>>463 どーでもいいから資料出せよ。別スレで出せって言ったろ？
ここで書いてもらっても構わん。
ソースだせ→スルーして他スレ荒らしは典型パターン
一々触るやつも同類まとめてスルーしとけｗ
>>459 一度納品して、検査がおわっても見つかってない不具合であれば、あとは保守の内容次第だと思う
管理者の日常業務にログチェックを入れてあればそのうち見つかる
定期的にログチェックをやってるなら、エラーが出てたらその時点で対応検討できるからな
一度作ったら放置のような客のとこでは、そういうのは無理だし、そこは割り切れ
まぁ、大きな問題になると困るようなシステムならある程度の管理者がつくから、
ちゃんとログの内容チェックしてくれると思うよ
全体仕様に関われる案件であることが前提だけど、
エラー時のログファイルを日時でファイル名分けた別ファイル出力するようにしておくとかやると
普段あまりログの確認をしないところでも、エラーが見つけやすくなるから、そういう手もある
あとはログチェックから不具合調査依頼を出すための資料収集の手順書を作ってあげたりすると
必要な情報が取りやすくなるので、不具合起きるとマズそうな案件とかでは重宝するかも？
別ファイル化は前後の記録が取れないから、面倒なこともあるので一長一短だけどな
あとはメール通知とかって手もある。大きなシステムとかだとログも膨大だから
>>455 そんなイラつくなよｗ
ちょっとキチガイなやつだ
そっとしておいてやれ
ふぅ。やっぱりこの結論に達するよねｗ
http://d.hatena.ne.jp/ryoasai/20110221/1298297258 システム系の例外は実行時例外＋AOPでハンドリングするのがベスト
インフラ層のチェック例外はやはりJavaのBad Partだと思う
運用環境で発生する可能性が常にあり、なんかしらの処理を行う必要があるものなら
Android触っててJavaの割には妙にストレスが少ないと思ったら
>>474 Androidは組み込みだからいつでも落ちますって前提。
中身ほとんどCで、システムのベースはC++だし。
JNIでC++アクセスできるなら、最初からC++ベースだけでもアプリ組めるようにしてほしいわ。
趣味マなんだけど例外って重要だと言われる割に
7スレ目でまだテンプレすらないぞ
>>478 ワロタｗ
そんなに複雑な仕組みなんてすてちゃえばいいのになｗ
だってそんなに複雑ってことはたくさんのバグや不具合を内包してるってことだろ？
try-catchについて本一冊書いてんじゃなくて、
>>485 だからそんな複雑なもんはいらねっつーのｗ
１０得ナイフを１０００得ナイフにして「ほら、使えるでしょ？ね？ね？」っていってるアフォといっしょだな
java で throws Exception をみかけるとやる気なくなる
ユーザー通知したり代替処理したりは普通にやるし、考慮されてなければ確認する
>>491 例外が仕様書にかいてんのもおかしい話だけどな
仕様書に書いてんのは、ErrorとWarningか復帰方法だろ
例外は相変わらずよく釣れるなｗ
>>491 ←こーゆーなんもわからない奴ってなんで減らないの？
>>494 たった１行で相手が「なんもわからない奴」って断言できる人間がいるからじゃないかな。
お前にとっては、いつまでも「なんもわからんない奴」だらけだろうよ。１行で判断するんだから
匿名掲示板なんだから1レスしか書き込まれなかったら
エラーはすべて例外にする例外原理主義
例外は東京電力の非常用発電機みたいなもの
IDやIPの類も無しに違う文体、違う内容を書きこまれて
>>502 おまえは一体何を言ってるんだ？
誰が「同一人物だと断定できる」とか、できないとか言ってるんだよ。
脳みそおかしいだろ
まぁ、「心療内科池行け」としか言ってないわな
昔からこのスレは頭の弱い子沸いてるんだから、いちいち構うなって
それをキャッチできずにスルーしてるからどうにもならんのじゃないか（´・ω・`）
使えないっていうか、理解してないし理解しようともしないし理解する能力もないっていう、そういうのが多い
いやそれは自分に出来ないことを他人に押し付けるのは誰もいい顔しないだろう
押し付けるとか、そういう使い方をするもんじゃないしなｗ
そんなに複雑な理由じゃなく、単に正しい結果を返せないなら例外だろ。
職場で例外処理使用禁止になりそうです。
>あるできるプログラマーが例外を理解してなくて
そんなんが「できるプログラマー」って時点で終わってるので、
運用時に例外投げてくれる可能性があるからＡＰＩのはなんとか握り潰して
その場で復旧できてそこまで共通化する必要があるなら
書き忘れましたが言語はC++なのでAPIが例外を投げてくることはありません。
例外発生時にいちいちキャッチする必要はないでしょう。
キャンセルするのに例外使うんだろ
>>524 エラーありか、無しかだけが欲しいなら
catch(...){}で捕まえても構わんのだぞ
まぁたしかにC++ならあんまり例外使いたくない気も。解放し忘れとかやっちゃいそうだし。例外使わなくてもやっちゃうんだけどさｗ
クラスきちんと設計できてるなら例外使わないとむしろめんどいケースが多いな
ああそうかそういうことか
> 書き忘れましたが言語はC++なのでAPIが例外を投げてくることはありません。
> 書き忘れましたが言語はC++なのでAPIが例外を投げてくることはありません。
環境を何も書いてないから例外を投げないAPIなのかも知れんが、どんなんだろ。
C++といってもぷち強いCみたいなのも結構あるからな
例外は基本システムエラーだけど
システムエラーじゃなくて
bad_alloc 受け取ったからって、アプリ側で何が出来るんだろ。
> bad_alloc 受け取ったからって、アプリ側で何が出来るんだろ。
その外人さんってリーナストパーズみたいな
C++はゲロ。低レベル開発はCこそ至上ってタイプのひとじゃないの？
例外投げると、オーバーフローとかthrowされない狭義の意味での
例外処理サボるから糞だと思ってるんじゃね。
多分暗黙の処理とかも大嫌いなんだろう。
>>541 キャッシュ用メモリの解放
応用として不要になってもbad_allocが発生するまでdeleteせず放置とか
もうなんにもできないくらい追い詰められてるのと
だよね。
>>543 個人的にだけど、C言語に極端に意識が慣れてしまうと、gcとか何かを完全に任せちゃってしまう
ようなものって逆に不安でさー。
便利だって意識より、俺の知らんところでこいつ一体なにやってんだろって気になっちゃう。
だから、頭では分かっていても使いたがらないというか。
例外も、自分でちゃんと処理書いてきっちりなにが起き得るのかを分かってて書いてしまいたい
という意識の方が強くて。普通の人ならいちいち書かないで例外任せにするようなチェックも
かいちゃうなぁ。まぁ、newとかで例外起きるとかってのは例外で拾うしかしゃーないけども。
あ、ごめん。
>>531 try-catch無い場合は余計階層が増えるんじゃないか？
でないとgoto使わなきゃならんはめになる
Javaはウンコ。
こんな下らないことで
>>549 このレスを見たおかげで
もう医者から治らないといわれ絶望していた
腰痛がなおりました
Javaもjavaだけど。
COBOL
素人でもできる、とかいう腐った台詞は40年前からある
あいちーは一気に広まって土方と同じ状態になった
士農工商からどう変転したものか、
産業革命の労働者と同じ
>>569 一応言っておくがな、
士農工商っていうのは、偉い順じゃねーぞ。
いやいやほんと
オブジェクト指向に関して否を唱えるスレを
OOに否を唱えてる奴らは
OOは現在一番使える技術で間違いはない
OOの次なんてものはない。
OOは使い方によってはそこそこ使えるぞ。
そもそもOOが構造化の延長だからね。
あんたが単に「分割して統治せよ」という大原則をわかってないだけ
>>587 が一体何に対して戦っているのか見えない。
ひとつ分かってるのは再帰で書くと
糞スレを立てまくったアホがいたからな。
えー、再帰なんか普通に使うだろ。
鉄器時代のFortranで育ったジジイが幅を利かせてた時代には結構あったのよ。
>>589 じゃ、今日からOO捨てて再帰で書いてみっつって出来るんですか？
お前の考えてる部分の再帰の話じゃないよ
なんで例外のスレでOO談義なんだ
uyはゲームが、ゲームがとやたら拘ってたが
>>593 このアホコテは昔から
「例外≒OO＝悪」
という超シンプルな間違った知識しか持ち合わせていない
そこから全く成長していないから相手するだけ無駄
その阿呆に釣られてOOの話を続けてる莫迦も
マ板にはアホだろうがなんだろうが全力で相手する暇人が多いからな
>>595 例外が悪とかいってないよ
オブジェクト指向（笑）やっていく上では例外に頼るしかないよね
それはどういうことかというと、
そもそもオブジェクト指向が斜めに立てられた建物であって
オブジェクト指向で大きなもの作っていくとどうしても
それを支える添え木として例外が必要になってる事に気づこうか
そもそもｗ newで例外が発生するからプログラマがそこにコードかくとかｗｗｗｗｗｗｗ
･･･OSか言語設計見直せよって話じゃん
OSや言語が斜めに立てられてるから、プログラマは例外で添え木をするしかなくなっているんだよね可愛そうにね
俺もRubyで例外は使うよ
でも静的言語で使うような例外ではなくもっとシンプルな使い方
method_missingも例外みたいなもんだしね
trycatchのどこにOOの入る余地があるのかわからん。
Google Goや、純粋OOP型であるVisual Works、
>>598 それより、ここ一年で何作ったんだよお前は
プログラム関連でいえば
例外なくてもOOは成立するだろ
visual worksにもpharoにも例外機構はあるが…
シェルスクリプトにも
例外の考え方としては、
例外は第3の選択肢であって、想定していない事象を握りつぶすことじゃないよ。
そりゃ想定してないのを握りつぶしたらダメだろw
>>604 参考にその例外機構を使ったコード書いてみて
>>604 汎用的なシグナル・ブロック・通常のメッセージ式の組み合わせで
ライブラリとして例外処理出きるようになってるだけで、
専用の例外機構なんてなくね？
>>609 Rubyで俺は、例外使うときにそういう使い方をしてるよ
利点としては、いちいちエラーの原因探るのがめんどくさいんだけど、なんか稀にエラーが出ちゃう場合に、
とりあえず例外で飛ばして次の処理にいく
そんなかなりアバウトなプログラミングが出来る
俺はこれを最近とあるマルチスレッドプログラミングで行った
500の何かがあった場合に、その中からエラーを出さずに使えるものだけ使い
ある処理をする場合にエラーの原因を探らずにプログラミングを続行するために例外を使った
> 利点としては、いちいちエラーの原因探るのがめんどくさいんだけど
>>612 MethodContextのソース読んでみるヨロシ
復旧できない例外を復旧できるところまでラップして投げたりするのは普通に当たり前のことだが、
つか、必要だからそのルート通るんでしょ？何から問題があったとして
理解してる
>>615 と理解してない617,618の違いはなんだ
赤信号でもプログラムを完遂させるようなソースコードなんて
普通書く奴いないから無視していいよ
イメージとして捉えられない奴にまで説明する気もない
別にそれを例外の正しい使い方だとか言ってないしｗ
> 理解してる
>>615 と理解してない617,618の違いはなんだ
俺がお前に教えてやるレベルだからじゃね？
へー
どうせ社畜プログラミングしかやってない子にはわからないんだから、
>>620 やっぱりuyは馬鹿だな。全然理解できないじゃん
>>615 ,617,618は結局全部間違いの指摘だろ
あの
>>614 の内容じゃ、俺馬鹿ですよ叩いてくれって言ってるようようなもんじゃないか
それとも、今度もまた以前の発言捻じ曲げて、都合よく解釈して自己弁護するの？
> それともチンコで釣りするのが趣味なのか？
糞コテは相手するだけ無駄だからスルーしとけ。
存在自体が例外みたいな屑ニートが例外扱いはダメって
>>623 >わからないものはスルーすればいいのに
そうやってわからない(理解できない)例外を全部スルーしてるってわけか
うちの数ヶ月で切られたゴミ中途も同じようなことしてたなｗ
また暴れるようなら再度過去のイタい発言集をテンプレにした隔離スレをたてるだけだな
例外が発生した時にその後の処理をすっ飛ばしたら問題だろ、
うゆは基礎学力をつけることをスルーしてきたからなぁ。
例外スレらしいオチも付いたところで、糞コテを補足して処理するのもこれくらいにしておこうか。
>>614 をしたり顔で書いてるの想像すると笑ってしまう
他人にソフト公開してる訳でもないクソコテにつきあうお前らってやさしいな
思うんだけど、俺がレスをしないとスレ停止してんだけど
元々過疎スレでたかが1日レスが無かったぐらいで何の問題が？
診断基準（アメリカ精神医学会 DSM-IV）
>>638 ＞見逃しているからフェアな比較ができてないだけ。
＞そしてエラー処理を入れ忘れてバグると。
処理書いてるからフェアかどうかって話ではないでしょ。
でもって例外だって例えばキャッチし切らずに抜けること
あるじゃん？でより上位の例外処理でつかんじゃって解析に
手間取ったり。
間抜けな話だがまぁそこまでいくと、どこ
までを処理の中
で想定できてるか、どこまで問題をとりのぞけるかっちゅー
話になってくるけどね。
一緒だよ。
>>649 デフォルトで処理が止まるのと進むのと、どっちが問題を起こしやすいか、
問題が潜在化・深刻化しやすいか、考えてみたら違いがわかるでしょ。
今ちょっと、
これから有名になって使われるであろうプログラミング言語のGoを見てるんだけど
http://ja.wikipedia.org/wiki/Go_%28%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E8%A8%80%E8%AA%9E%29 ＞例外処理やクラスの継承、ジェネリックプログラミング、アサーション、オーバーロードといった機能が存在しない
らしいですよｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
例外厨涙目ｗｗｗｗｗｗｗ
Googleのｗｗｗｗｗｗ博士級の人達がｗｗｗｗｗｗｗｗ例外はいらないと言ったんですねｗｗｗｗｗｗっうぇｗｗｗｗｗｗ
そりゃそうだよねーーー
>>651 悪い悪い。訂正しておいたよ。
> クラスの継承、ジェネリックプログラミング、アサーション、オーバーロードといった機能が存在しないことも特徴として挙げられる。
> try-catchはないがそれに代わる機能としてpanicとrecoverを用いた例外処理をサポートしている。[2]
> FAQにおいて、ジェネリックプログラミングは一部導入が表明されているが、オーバーロードは効率的見地から排除されたことが述べられている。
> 関数は多値を返すことができるので、それによりエラーの報告は容易である、としている。
英語版を参考に、もうちょっと追加したよ。
Googleの中の人のプログラミングがダメダメなのは
インターフェースがあってクラスの継承がないというのを見ると
マ板でtypoする奴がいるってのが信じられない
Cの代替言語で何かする気にはなれない
Goのdefer文とpanic-recoverの仕掛けは実際良くできてるよ。
一番マシなのは「；」 末尾のこれがない事だろ
uyしっとるか
>>655 どうでもいいがtry-catchだろうが、recoverだろうが例外処理って書いてるのおかしくないか？
こういうのは、あくまで例外機構であって、例外処理は人間が書くものじゃね。
>>664 枝葉末節はいいから、他人に見せられるソフト作って公開しろよ
ソフト一つ作れん言語オタクの戯言なんざどうでもいい
コードはよく出してるよなuyは。他人に見せられるかどうかは…
すぐ例外と関係ないことに流れて自分の主張すら忘れる程度の知能しか持ち合わせてない
C++だと、例外はファクトリメソッド内以外ではcatchしない
> オブジェクト生成時に発生した例外だけはエラー戻り値に置き換える
つか、C++の例外は途中でCがはさまったりすっとややこしいからなぁ。
>>676 えとね、コンストラクタで例外だしていいんですよ。
どっかの馬鹿本がだめとか間違ったこと
書いているのがいけないんだが。
というかRAIIというベストプラクティスが一般的になる前に、「C言語禁じ手」っていう
あと、どこでcatchするかは処理次第だから、
ラップされてるんならいいんだけど、ラップもせずに例外上げてくるのがむかつく。
>>682 エラー処理めんどいってことだろ。わかるわかる。
異常系考慮しないマほど例外を嫌うイメージ
そもそも、知る必要ないものばかり投げてくるじゃん。
確かに知識がないことを棚に上げて文句言ったりする奴が多いな
>>685 たとえばどんな例外のこと言ってるの？
プロジェクト内の話ならお前がダサくないように修正を提案すればいいんじゃないの？
例外クラス(値?)をどうデザインするか迷う。
JavaでWeb系なら、基本的にはRuntimeException継承した業務レベルのエラー1つだけにしておくかなぁ
>>688 同じ意味合いのある例外ならそういう集約の仕方はありだと思う
型が同じだと違和感があるような例外であるなら、元になる例外を継承して複数のクラスにする、とかでもいいと思う
普通にクラスを作るときと同じ感じで設計するのがいいんじゃね
同じオブジェクトとして扱うべきものかどうか、が判断条件
個人的には、クラスファイルが増えること自体は、全然面倒だとは思わない
中身に文字列しか持って無いようなのが困るんだよね。
try{}
まず、お前がそういう研修を
え、
え、
え、
アセンブラーのライブラリは、アセンブラーのライブラリだから多少面倒だろうな。
DLLを使用してるアセンブラーなんて多く無いだろうから
先日またやられたわ…
>>704 その馬鹿も、昨日今日沸いたわけじゃあるまいに。
誰が見ても駄目なコードを放置しておいたお前も悪い。
見れば一発で駄目だってわかるじゃないか
>だいたいこれじゃ絶対例外飛ばないし
関係ないがthrowsにException書くのは、俺はありだな。
例外検査に必要なのは投げる可能性が有るか無いかだけ。
個別の型検査は、オーバーライドが有る以上邪魔なだけだ。
http://www.ibm.com/developerworks/jp/java/library/j-jtp05254/ C++でも例外に対し警告を出せるthrowの元になった仕組みがあったが結局使われず
投げない事をしらせる意味しか無くなった。挙句は、それせんようの構文までできた。
挙句.net環境においては採用されず、後続の言語にも採用するものは居ない。
そういうのは実行時例外で事足りるだろう
もうみんな匙を投げちまってるんだから今更言っても遅い。
検査例外自体、上まで投げ返すような使い方するもんじゃないしな。
ないわー、まじないわー。
>>715 理想論はいいとして、throwsへの派生型記述にこだわると何が嬉しいの？
開発経験ながけりゃ派生型の固有の情報が欲しい時なんて必要に応じてぐらいで
毎回必要とされる機会なんて殆ど無いはずだが。
開発経験の長い人で派生クラスだけをthrowsに書けって人は、
全部のメソッドにthrows Exception書いてるプロジェクトは色々死んでた記憶しかないな
珍しくスレ伸びてるね。
>>721 どんな様子だった？
例外握りつぶす馬鹿が参加してたとかそんなオチはやめてね。
そういう馬鹿が居るのはは、チェック例外に限らず全般に言える問題だし。
>>722 あるさ。例外を投げる。投げないって事は解る。
C++11にもそういう機能が登場したしね。
無効な値を返す、または、オブジェクトが無効になる可能性がある→例外処理必須
RuntimeExceptionを祖先にもつ例外だってthrowsに書けるし、javadocにも書けるから、意識できないわけじゃないよ。
実行時例外と検査例外の差は補足の有無をコンパイラがチェックするかの違いだけ。
処理済みでかつ一部の共通処理以外では補足の必要がない状態になった例外までコンパイラーに検出させる必要ない。
なので実行時例外へ纏めてしまう、って手法は、汎用的なフレームワークとかでも使われてるよ。
むしろ後から例外が増えた場合に影響ないように、なんて理由で、親のタイプでthrows節に書くのは、
Exception型でcatchしたりすることが増える要因を作ったり、多数のメソッドに検査例外のthrows節が必須になったりして、
無用な補足を多数繰り返すようになったりしてNG。間違いを招きやすいので、これはやっちゃいけない。
そんなことをやってしまうと、とたんに検査例外の意味がなくなってしまう。
プライベートメソッドでthrowsで例外を伝播させていくとかであれば、一クラス内で収まるし大きな問題にはならないけど、
protected や public メソッドでそれをやるのは、やっぱよくない例外設計だよ。
そういうのが蔓延してしまうと、不必要な補足をされてしまった場合に、機械的に検出するのが難しくなる。
チェック例外のビルドエラーを発生させないように記述する方法はいくらでもあるからね。
一部の共通の例外処理を除いて、catch(Exception e) のようなコードに記述させないルールのほうが、
徹底しやすく機械的な発見もしやすいから、意図しない例外処理が発生する要因を減らせる。
このあたりの使い分けに方ついては、別に最近出た話題でもないので、情報は結構あるよ。
http://www.google.co.jp/search?q=%E5%AE%9F%E8%A1%8C%E6%99%82%E4%BE%8B%E5%A4%96 >>721 それは、実装ではなく設計の問題じゃないかな？
継承をすることでメソッドの役割や機能が変わってしまってるので、祖先のメソッドが限定的過ぎたか、
子孫のメソッドが異なる役割を持ったメソッドになってる、ってことが本当の問題だと思う。
事前に集約されたタイプでの throws に"しておく"のは、
そういう問題が起きたとき、場当たり対応しやすいようにするためのアンチパターンでしかないよ。
もちろん、集約したタイプでの throws 節を書くな、という意味ではないよ。
>>724 検査例外は、例外が発生するしないを伝えるためのものではなくて、
その例外の補足の必要があるかどうかを、必ずコーダーに判断させることを強いるためにだけ、使うべきだと思うよ。
なので、アプリケーション全体で、処理済みであったり補足の必要がないのがわかりきっている例外まで、
検査例外でビルドが通らないようにしてしまうのは、検査例外である意味をなくしてしまってる。
そして「ビルドを通すようにする」という本来の目的ではない理由で、
例外の補足か伝播をハードコーディングする必要が出てきてしまう。
例えば、ぬるぽやIlligalArgument、UnsupportedOperationなんかが実行時例外になってるのも、同じような理由。
これらが発生するのは、基本的にコーディングのミスによるものなので、普通は補足しちゃいけない。
補足してｶﾞｯするのではなく、発生しないようにコーディングで回避すべきことだしね。
同様に、処理すべき場所が明確に定まっているような例外であれば、関係のない場所で勝手に処理されてしまうのはバグ。
しかし、関係のない例外処理が随所に入るような例外設計になっていると、それを機械的に見つけるのが難しいくなってしまう。
検査例外がない言語であれば、例外処理をしている箇所を抽出すれば勝手な処理を発見できるけど、
先に書いたような、ビルドを通すためだけの例外処理が随所に出てきてしまうようになっていると、抽出が難しくなっちゃう。
だから検査例外が無駄になってるって話だと思う。
あ、呼びもとの例外処理を意識した例外のスローが云々は勿論理解しているよ。
>>726 RuntimeExceptionを代わりにつかうのはアンチパターンだよ。
普通バグかランタイムシステムの異常だからね。
>なので実行時例外へ纏めてしまう、って手法は、汎用的なフレームワークとかでも使われてるよ
実際のクラスドキュメントへのリンクを貼ってくれるかい
>>727 理想論はいいんだけどさ、具体的にどいう風なコードでどういう問題が発生するか書いてよ。
Exceptionでthrows指定した時点で理想は捨てて実利をとりに言ってる訳だから。
>なので、アプリケーション全体で、処理済みであったり補足の必要がないのがわかりきっている例外まで、
>検査例外でビルドが通らないようにしてしまうのは、検査例外である意味をなくしてしまってる。
>そして「ビルドを通すようにする」という本来の目的ではない理由で、
>例外の補足か伝播をハードコーディングする必要が出てきてしまう。
例えば、実際にはこういう問題は起きないでしょ。
throwsにException型を書くのはその問題の典型じゃねｗ
try{・・・・}
catch( RuntimeException exception ){ throw exception; }
catch( XxxxxxxException exception ){ /* Xxxxxxx固有例外処理 */ }
catch( Exception exception ){ /* 一般例外処理 */ }
これだけの事だろうに、なんで
>>730 みたいな話になるんだ？
単に教育が悪いだけじゃないか？
RTEキャッチして再スローとか随所に書く必要があるとかアホだなー
RuntimeExceptionにねじ込んでcatchできなるくなる事に比べたらその程度の手間は気にならないよ
斜めにしか読んでないけど、例外処理は絶対にこうしないといけないっていう厳密な縛りはないから、
小さいプロジェクトなら追っかけりゃ大体わかるしあんまり気にならないけど
Exceptionをthrowsに入れるのはRuntimeExceptionで投げるのと変わらないって人は、
↓のような例外の要、不要なメソッドを分けられる事についてどう思ってるの？
RuntimeExceptionでも同じ事ができるの？
// finalで例外を出さない( コンストラクターでも同じ )
example.thomethingA();
--------------------------------------------------
try
{
// finalではなくオーバーライドされてる可能性がある
// また、throws Exception,・・・で宣言されいる
example.thomethingB();
}
catch( RuntimeException exception ){ throw exception; }
catch( Exception exception ){ /* 一般例外処理 */ }
>>735 人間的な問題は現場の教育次第だし不毛だから置いとこうよ
やっちゃいけないといえば、メソッドの最初でtry書いて最後にcatch書く奴とかもあるなｗ
Exception型投げてくる奴多数あると面倒だからそう書いちゃうけどｗｗ
>>737 だれうまｗｗ
べ、べつに毛がないわけじゃないぞ…！
>>736 実行時例外ラップの話って、そもそもExcepton型でのキャッチや実行時例外のキャッチはさせない設計が前提の話じゃね
その場で捕まえないといけない例外はそもそも処理してまとめてから投げるか、
適切に復旧してもみ消して外に投げないから、派生クラスで限定的に書いても問題ないのでは？
色々ごっちゃになってね
>>735 細かく書けるなら書くに越したことはないけど、
オーバーライドで変わる場合はコメントに何を期待するの？
この辺は結局、インターフェースを実装する側に合わせるんじゃなくて、
使う側の都合でコメント書くしか無いんだろうな。
「この@throwsに書いてある例外がなげられる」じゃなく
「この@throwsに書いてある例外は呼び出し側の処理に使用される」ってな感じ？
つかなんかこう視点が違うな
全体の設計的な話してる奴と個々のクラスの実装担当者みたいな視点で話してる奴とじゃ噛み合うわけない罠
あとは想定してるアプリケーションも違いそう
Strutsとかつかってやるようなウェブアプリケーションと、その場で復旧して処理を続行するような落ちないシステム、みたいな
なんにせよ
>>734 、プロジェクト内でちゃんと統一が取れててハゲの原因を生まなきゃ何でもいいさ
>>740 javadoc勉強しなおしな
@throws には型とその例外がスローされる原因なり条件なりを書くもんだ
インターフェイス仕様のドキュメントなんだから、何をしたら発生するかっていう仕様を書くだけ
まぁjavadocちゃんと書けてる奴って、実際あんま居ないけどな…
あとオーバーライドしたらインターフェイス仕様変わるとか、そのクラス設計のほうに問題あんだろ
try {
>>742 「」の中はコメントの内容言ってるんじゃないよ
throwsに列挙される例外の条件を言ってるんだよ
>>739 例えば、こういう処理にそのRuntimeExceptionの設計思想を入れるとどうなるの？ {}の位置とか()内のスペースとかなんか気持ち悪い
うむ、括弧のスタイルは統一してくれ
こういうへんなコード書くおっさんがうちの職場にもいるけど例に漏れず例外も正しく使えてないな。
あと、人のソースに手を入れる時に、はじめに作った人とは明らかに異なるスタイルで追加する人いるよな
とはいえあまりにヘンな俺様ルールには従ってられないじゃん
まともな意見もだせず関係ない話で叩こうとする
>>751 ブロックが横に続いてんのは2chだからだと思うぞ
どうでもいいことに反論するのもアレですが、
反論するってことはどーでもよくはないんだよ
この程度で読みにくいとかイライラするようなプログラマはいらねーな。
俺は
>>746 の書き方に似てるから叩かれてる理由がわからんな
統一してくれって書いてるやつがいるが統一されてるし
>>760 ストライクゾーンの違い、それだけのことだよ
>>746 >>754 ＞{ throw exception; }こういう書き方したのは 単に書き込み行数を減らすためです。
javaは知らんが、C#の場合
http://d.hatena.ne.jp/aoki1210/20091007/p1 ↑
みたいな話がある。
こういう勝手をやるのがMSのダメなとこ
>>762 C++の構文をそのまま持ってきてるだけだけどな
>>763 げんごしようをりかいしてないことがもんだいなのでは？
>>765 Vistaを理解してないことが問題
Excel2007を理解してないことが問題
とか言ってるのと同じだろ。ダメなもんはダメなんだよ
理解してないことが問題だと思う人は、理解せず使えるものを使えば良い。
Vistaの不満もOffice2007の不満も、どっちも理解力がないゆえにの部分が大半だけどな
道具を理解しないで許されるのは素人だけだろ
>>767 ＞理解してないことが問題だと思う人は、理解せず使えるものを使えば良い。
普通「理解してないことが問題だと思う人」は、理解してから使おうとするんじゃね？
理解にかける時間が妥当かどうか判断してからどちらにするか決める
そら、PC使ってるからCPUの仕組みを理解しろとか、半導体物理理解しろって言われたら、理解しなくてもいいだろうけど
ローカル変数を理解しなかった連中の末路を知らないのだろう
>>769 難解な新製品を使わずに
手慣れた製品を使えば良い仕事はできる
>>765 少なくとも、
>>746 はJavaの言語仕様理解してるし、JAVAで書いてるんだから何の問題もない。
恐らく、
>>746 であれば、C#で書く場合、ちゃんと
>>762 の仕様も理解して守ろうとするだろう。
全然問題なし
2chMate使うとよくぬるぽが出るのをどうにかしてほしい
話題の発端は、ここで語るような内容でもないから要らない誘導だろ
多いね。とても多い。
Javaの検査例外は最近使わない事のほうが増えてきたな
お行儀の良い使い方ではないけれど、処理抜けを行うgotoとして例外をつかったフレームワーク、
>>784 構造化じゃ書けないエレガントさってあるよな
Switchの流れ落ちとか
構造化じゃ書けないとか言いながらswitch文使うとか、意味不明
cだとswitchのcaseブロックはbreakしなければ下のcaseに流れ落ちることができる
「構造化の観点から」じゃなくて、しばしばバグの原因になってるから、という理由。
C#のswitchではfallthroughの代わりに、
例外じゃないけど、goto case、便利だよな
フォールスルーを構造化の観点から禁止するなら、
UMLで例外を一生懸命書いてるバカが居たな。
なんのためのモデリングツールか理解出来ないうちはあんまり役に立たないね
例外処理は急ぎの仕事の時に助かるぐらいのつもりで使ってる。
例外処理って昔の言語にはなかった
例外で重要なのは例外そのものではなくてその後のfinallyブロックだと思うｗ
もう例外なしじゃ生きてけない
>>796 finallyなんて大した機能じゃねーよ。
例外で重要なのは、関数コールスタックを
（途中でキャッチしない限り）
自動的にさかのぼるという機能。
finallyはガベージコレクションなどの
スコープ抜けたら自動的に後始末してくれる機能が
あれば殆ど使わない。
GCは「スコープ抜けたら自動的に後始末してくれる機能」じゃないし
> ガベージコレクションなどの
後始末が不要な言語、
斜め上すぎてどう突っ込んだらいいのかさえわからないレベル
>>803 の意訳
突っ込みたいけど突っ込めない悔しい。
と皆思っただろう。
突っ込みたいけど突っ込めない悔しい。
>>800 スマートポインタを指して「ガベージコレクトなど」と言うのは、
イギリスを指して「フランスなど」というようなものだぞ。
で、それを指摘されたら「ヨーロッパを知らないのプゲラw」って言うようなw
どこにもスマートポインタの話なんか
突っ込みたいとかなんとか、卑猥な話題してんな…
例外キャッチして数値フラグや文字列フラグで返す処理を量産する馬鹿がいたり
ライブラリがせっかく理想的な例外を出すのにそれを俺様流でぶっ潰すのがうまい奴が大杉
少なくともハード屋の書いたソースでコードレビューは通らない
例外面倒くさすぎね？
>>818 よくわからないんで状況のサンプル書いて。
エラー処理なんて例外じゃなくてもそうなるんじゃね？とも思う。
例外をcatchしようという発想が間違いの根元やね
戻り値によるエラー値のif文判断の脱却が例外catch
受ける会社大丈夫？
javaでは
性的解析ツール使って、commitさせないように、commitされてもすぐに検知するようにするしかないね
【 オンラインTCGエディター 】 >>1 http://wc2014.2ch.net/test/read.cgi/entrance2/1444545761/-20 ヘボプログラマは例外クラスを定義することに怯えすぎｗ
>>827 JavaやC#前提で話すけどさ、
不特定多数から利用される、コアなライブラリなら、
独自例外クラスを定義し、それを投げる方がいいと思う
一方、アプリに一番近い層では、独自例外クラスの手法だと、
作成クラス数が多すぎてプログラムが煩雑になりがち
メッセージの国際化もやりずらい
例外クラスは、なるべく数を抑えて(2〜4くらい)、エラー番号を埋め込んだ方がいい
って思ったりする
独自例外なんていらなくね?
>>829 ビジネスエラーを表す独自例外がないほうがエラー処理面倒でしょ
>>831 独自例外を定義してる3流ライブラリもたくさんあるねｗ
システムエラーは例外、ビジネスエラーはエラーコードだな。色々考えると、それが正解。
>>833 つまり、例外機構はシステムエラーのための仕組みということ？
残業SEは大迷惑！
>>833 でもさー、catchしたときに違う処理したい場合ってあるじゃん。
エラーコードみてif文とかで分岐するの？
匿名通信（Tor、i2p等）ができるファイル共有ソフトBitComet（ビットコメット）みたいな、
BitTorrent（Covenant）が活発な情報交換・交流コミュニティでオープンソース開発されています（プログラマー募集中）
言語は何でも大丈夫だそうなので、P2P書きたい！って人居ませんか？
Covenantの作者（Lyrise氏）がそういう人と話したいそうなので、よろしければツイートお願いします<(_ _)>
https://twitter.com/Lyrise_al ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできない情報発信好きアスペルガーｗ
通話料が激安になるブラステル（050 Free）で、かなり遅延や音声途切れが発生する方は、以下の設定を試してください
○ Wifiと３Ｇのコーデックは２つ（GSM、G.711u-Law）とも有効にしておく
○ エコーキャンセルをOFF（チェックを外す）にする
○ あとの設定はデフォルトのまま
http://blog.livedoor.jp/gnunobian/archives/52013458.html 上記の設定でも音質が悪い方は、wolfsonの高音質チップを搭載した機種（Galaxy 初代S、S3、S6、 AQUOSPhone ZETA SH-06E、AQUOSPhone si SH-07E、AQUOSPhone Xx 206SH、 Galaxy Note II）に買い換えて下さい。
500円以下の格安SIMで使えて登録・月額無料、IPベース発信なら携帯へは5.5円／30秒、固定へは8円／3分（月額無料でこの価格はすごい！）
http://blog.jikoman.jp/2015/11/brastel-050-free.html あと、050Freeの起動もしくは発着信が２週間以上ないとプッシュサーバー期限切れでプッシュ着信が出来なくなるので、Llama Location Profilesで１週間に一度050Freeを自動起動するように設定すると、２週間以上経過してもプッシュ着信できます
最後にロケットストーブの焚き口へ超省電力なDC扇風機で風を送ると、横引き煙突が12ｍ以上あっても煙が逆流してきません。
よって、横引き煙突で超高効率な熱回収ができるので薪が少量で済みます
あと、燃焼室の大きさは『無煙竹ボイラMBG150』で検索して参考にして下さい
１４
>>1 スレッドタイトルがおかしい。
例外処理がおかしい、例外処理がない、エラーハンドリングがないなら分かる。
例外の扱い方というより、例外処理のプログラムが変なのは、ただのプログラミング初心者。
>>837 そういうことだろう。
ビジネスロジックで、分岐判断してるコードとその結果を判断するコードが
離れまくってるってのは大概問題ありなコードだろうし、直す必要があるって
兆候と見ていいんじゃないかね。
おいおい何ヶ月前のレスにレスしてんだよ・・・
throwが｢投げろ｣の意味がいまいち分かりませんが…
throw 今から投げるよんー
>>849 何となくわかりました。
>>847 >>849 ありがとうございました。
誰でも簡単にパソコン1台で稼げる方法など
とても簡単な自宅で稼げる方法
このスレへの固定リンク： http://5chb.net/r/prog/1306646249/ ヒント： http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
>50
>100
>200
>300
>500
>1000枚
新着画像 ↓「例外を正しく使えないプログラマ多いね。 その7->画像>5枚 」 を見た人も見ています：・プログラマーはMacユーザーが多い プログラマーってなんで不細工で陰湿な男が多いの？ VIPってプログラマー多いみたいだけど普段何作ってんの？ 数学ができないプログラマ テスト描かないプログラマー bashとEmacsはM1搭載Macで動かないプログラマ気をつ センスのないプログラマはやめろ 自分に自信がないプログラマー プログラマーならわかるすごいプログラムゲーム HTML/CSSが書けないプログラマー 電子工作のできないプログラマは時代遅れ 人生で１度も１番になったことのないプログラマ モテないプログラマ、クリスマスどーするよ？ バグの少ないプログラマーほど自分を客観視出来る 【ＩＴ】能力の高いプログラマーほど数学力より言語能力が高いという研究結果 日経名物記者木村 岳史がIT土方モメンに喝！仕組みを考えない「自称プログラマー(コーダー)」はエンジニアにあらず！ 優しいプログラマーのお兄様方教えてください。 プログラマの仕事着＝私服。スーツ？ありえないｗ 日本のプログラマーのレベルが低いのって会社でちゃんと教えないからだろ 【IT】人気が下降しプログラマの求人も少ないプログラミング言語ワースト10は？ メモリ管理やポインタすら使えないやつがプログラマ名乗ってるのクソ笑えるんだが😅 プログラマ川柳 プログラマー組合 腱鞘炎のプログラマー 田舎でプログラマやってるやつ 執筆するプログラマー プログラマーの時給 プログラマと血液型 独り身プログラマ プログラマーの子育て 30代のプログラマーいる？ プログラマをPGと呼ぶ奴はバカ プログラマーの川柳・俳句 馬鹿プログラマの集会所 筋トレしてるプログラマー 徹夜したプログラマー プログラマのIQ 使えるプログラマになりたい 派遣プログラマの面接 A型のプログラマーは神 派遣プログラマよ プログラマの借金事情 プログラマーは売春婦と同じ 独身プログラマの作る料理 プログラマの学歴ってどうよ？ プログラマに復帰したい プログラマーと風呂 プログラマの出会い プログラマーの転職 プログラマーはきもい プログラマーの食事 プログラマの雑談部屋 ★79 プログラマの雑談部屋 ★84 プログラマの雑談部屋 ★172 認知が歪んでいるプログラマ プログラマの座右の銘 プログラマーの転職 プログラマーの昼食 プログラマの最終学歴 40代のプログラマー 自分の子をプログラマにする？ 英語が苦手なプログラマー 声優プログラマって プログラマとテスター
03:54:16 up 18 days, 14:18, 0 users, load average: 11.35, 9.63, 8.90
in 0.074272871017456 sec
@0.074272871017456@0b7 on 123017
