例外を正しく使えないプログラマ多いね。 その7

1 ：2011/05/29 〜 最終レス ：2013/09/17

例外にまつわる内容であれば、不満でもネタでも主張でもご自由に。
@throws Threadが100を超えましたException
　　　スレッドが埋まってしまった場合に送出されます。
　　　>>980 を超えたら新しいスレを準備してください。
@see 前スレ
　　　例外を正しく使えないプログラマ多いね。 その6
　　　http://hibari.2ch.net/test/read.cgi/prog/1298059471/

2 ：

>>1
Java前提にすんのやめろよ。

3 ：

むしろ例外の扱いが微妙なC++のほうが話題多そう。

4 ：

javadoc形式のタグは他言語でも似たような形式で流用されてるの多いしJava前提ってわけじゃなくね
他の書式はXMLドキュメントくらいしか知らんけど
javadocといえば、@throws タグで例外の説明んとこに
「例外を発生させます。」とか「例外が発生した場合。」
とか書く奴が結構多いんだが、これも正しく使えない奴の所業だよな
全く持って説明になってないから、結局何が原因で例外投げるのかがわからないっていう…
勘弁して欲しいわ

5 ：

まともなコードヒントが出ない場合、発生する例外がわかりにくくて手間かかるわ

6 ：

javadocはもう一段進化するべきだな。
引数とコメントの両方に同じ名前を二度書かせるな。
/**
* Validates a chess move.
* @author John Doe
* @param theFromFile File of piece being moved
* @param theFromRank Rank of piece being moved
* @param theToFile File of destination square
* @param theToRank Rank of destination square
* @return true if a valid chess move or false if invalid
*/
boolean isValidMove(int theFromFile, int theFromRank, int theToFile, int theToRank)
↓

boolean isValidMove　　　　/** Validates a chess move. */
(
　　　　int theFromFile　　/** theFromFile File of piece being moved */,
　　　　int theFromRank　/** theFromRank Rank of piece being moved */,
　　　　int theToFile　　　/** File of destination square */,
　　　　int theToRank　　/** Rank of destination square*/
) /** true if a valid chess move or false if invalid */
{
}
ここからドキュメントを生成できるようにしろ。
ちょっと冗長になるだろうが、/** */じゃなくてアノテーションでもいいぞ

7 ：

/**
* Validates a chess move.
* @author John Doe
* @param int theFromFile File of piece being moved
* @param int theFromRank Rank of piece being moved
* @param int theToFile File of destination square
* @param int theToRank Rank of destination square
* @return boolean true if a valid chess move or false if invalid
*/
isValidMove {
}
逆にコメントだけあればよくないか？

8 ：

自動生成で事足りるし、そこまで手間だとは思わんな
しいて言うなら引数名変えるとき追従して欲しいってくらい
コメントの拡張はあくまでもコメント、コードはコードでわけてたほうが、
なんだかんだで見やすい気がするわ。つか、スレチだけどなｗ
例外へのドキュメントコメントは、まともにかけてる奴殆どいねーわなぁ
それ以外のですら省略されがちだったりするし。酷いとこはほんと酷い(´・ω・｀)

9 ：

つか元々言語とは別もんの機能なんだから、
IDE辺りがコメントの同期をサポートするのが筋だわな。
言語に依存関係に無いはずの別システムのサポート組み込むなんて
ガラパゴス電話の失敗と同じ。

10 ：

> 言語に依存関係に無いはずの
いや、コメントは依存関係ありまくりだろｗ

11 ：

　コメントの内容は依存したらいけないだろ。
TCPのデータ領域をTCP階層で監視するようなもんだぞ。
もしjavadoc以外の高性能なツールがでてもjavadocへの
言語サポートが干渉してJavaではそのツールを使えなくなる。
javadocの内容をコメントから外してアノテーションのプラグマとして管理するなら別だろうけど。

12 ：

連動も面倒もどうでもいいから
発生する例外の詳細くらいはちゃんと書いておいてください＞＜

13 ：

>>11
>コメントの内容は依存したらいけないだろ。
本来そうなんだけど、PostScriptってページ記述言語が有ってじゃな…
>TCPのデータ領域をTCP階層で監視するようなもんだぞ。
FTP...
IPv6に成ったら、FTPは撲滅して、scpかbit torrentに移行すべきだな。

14 ：

>>9
どんな古いIDE使ってるんだw
時代遅れにも程があるぞ

15 ：

>>14
コメントを変えると同時に引数名が変わったり、
引数が削除されるIDEがあるのか最近は凄いな。

16 ：

コードで表現できてるのを、コメントで二度書ききなきゃならないコードを、プロは書かない。DRYに反する。素人の糞コード。
コメントで言い訳書かなきゃならんコードをプロは書かない。それを設計とコードで表現する。
クライアントへの契約、を表現するドキュメンテーションコメントのこと言ってるなら、それはIDEがリファクタリングで連動して変換する。手作業の出番なんかない。
めんどくさい手作業をしにゃならん、と感じる状況を手作業でせっせっと勤勉にやってる時点で石器時代の土人。どんだけゆるい思想やプライドで職業ついてんだ、
発想の根本がこの業界にむいてない。

17 ：

>>16
うん。だから>>6-7のように
コメントとコードが一体になる方がいいと言ってるわけだ。

18 ：

IDE好きはJava土方と相場は決まってる

19 ：

>>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点目。
スレタイの「例外」に全く関係ない。

20 ：

コメントに「何をするコードか」ばかり書いちゃう奴は修行が足らん
そんなのは命名センスや設計センスがしっかりしていれば、最小限で済む。
それよりコメントには「なぜそのコードが必要か」に重点が置かれていないと意味がない。
最悪「何をするコードか」はコード読めばわかるのでわざわざコメントにかかんで良い。

21 ：

何をしてるのかが分からないコードの多いこと

22 ：

>>19
お前はピントがズレていると言ったが、
本当にピントがズレているのはお前の方だ。
コードの中身に文句をつけてどうする。
それはあくまでサンプルであってコードに意味はない。
別にコードの内容を指摘されて悔しいから言っているわけじゃないぞ。
なぜならそのコードはwikipediaから拝借したコードだからだ。
http://ja.wikipedia.org/wiki/Javadoc

23 ：

コメントというか、関数名の頭に描くべきものは、
例えばman sprintfをして表示されるようなものだ。
つまり、関数の引数の説明とか、
戻り値とか、そういう言うものを書くべきだ。
関数の頭にね。

24 ：

引用元がどこだろーと、下手なコードが下手なことに変わりはないなw
コード批判はしてるかもしれんが、より本質的には発想批判だろ。
>>6の思考は、同じ名前二度書かせるな→まとめて書いちゃえ
というのが中途半端なんだよ。
コメントなくても通じるコード書けば十分だろ？っていう指摘。
doclet捨ててなおAPIドキュメント作りたいんなら、わかりやすいコードだけ書いて
リフレクションでAPI生成してろよ、
って普通思うんじゃねーの。
無駄だって問題提起しながら、そこで出した解決策がこれまた無駄だから揶揄されてるんだろ。

25 ：

> コメントなくても通じるコード書けば十分だろ？っていう指摘。
コードはコメントがなくても通じるかもしれんが、
引数はコメントがなければわからないぞ。
お前は経験がない。知識だけでものを行っとる。

26 ：

特に戻り値は型しか書いてないから、
名前で意味がわかるなんて不可能だな。

27 ：

それは、名前の付け方が悪いんでねーの？
ってこと。
コメントで書く説明を、書かなくていいよーな引き数名にすれば済むでしょ。
そーいう発想で書いてみ？
キチンとしたコードが書ければ、「おいおいコードに書いてあるだろ？」って
コメント書く時間が無駄に感じるから。
で、コメントにはコードの説明なんかアホらしくて時間の無駄だな、ってのがスタートラインだ。
当然、コメントにはもっと別のことを、書く。

28 ：

プログラマに平和はないな

29 ：

コードを読めば分かるというのは、
逆に言えば、コメントがあればすぐに分かることが
コードを読まないとわならないってことだ。
コードを読む時間が長くなるのなら、
コメントを付けるほうがいい

30 ：

>>26
それはプリミティブで返すからだろ。
エリックエバンスの本とかにも分かりやすい説明あるぞ

31 ：

>>29
違うだろ、コードの使用者の感心ごとは、コードの中身じゃない。契約だよ。
中身なんか読まずに済ませたい。
読む必要がないよーに、シグニチャを設計するんだよ。
それが良いコード。

32 ：

>>27
> コメントで書く説明を、書かなくていいよーな引き数名にすれば済むでしょ。
> そーいう発想で書いてみ？
じゃあお前はsprintfという関数の引数として
何が使えるかを、どうやって引数名に含めるんだ？

33 ：

double pow(double x, double y)
多分こんな定義に文句をつけて、xとかyとか使うな、 x の y 乗なのか
y の x 乗なのか、わからないだろ。関数の引数名はもっと長く書けとか
的外れな文句を付けてるようなレベルの人だろうな。

ドキュメント読まないで、引数の名前で推測して
コーディングするやつにまともなコードは書けない。
世間で言われている、「コードの内容を示すコメントを書くな」というのは
i++; // iを一増やす
のようなコメント一文 と コード一文 が完全に対応している場合の話だ。
世間で言われていることを鵜呑みにして、本質をちゃんと捉えてない。

34 ：

つか、関数にする理由は、
長いコードを読まなくて済むようにするのが目的なので
コードを読めば分かるというのは、
関数そのものを否定しているのと一緒。

35 ：

>>32
先に白状しとくと、俺はC使いではないんで、妄想込みだから脳内保管してくれ。
推測するにsprintfは、
フォーマットとかメッセージを例えば渡すんだろ？
だったら、型抜きで書くなら
sprintf(message, format)
あたりだろ。
messageの型はobjectなのか？各型ごとにオーバーロードしてるのか？その辺りのニュアンスはC使いじゃないんでよーわからん。言語特性にあわせてよろしく定義されてるんだろ。
戻りはvoidあたりか？
で、format辺りは文字列でやってんだっけ？そーすると渋々ドキュメンテーションコメント書く系統の設計になりそうだなこりゃ。
ま、こりゃコメント書かんとダメだな、ちっ、っていう例だと思う。

36 ：

>>33
なんか怒らせたっぽいか？すまんな。
だが現場の経験から話してるぞ。
ドキュメンテーションコメント見ながら、コード書く奴がいるのか？を冷静に思い出してみてくれ。
言語そのものといっていい組み込み関数だかAPIだかライブラリの話じゃないぞ？
おまいやおまいの同僚が、昨日や今日書いた、あるいは今さっき修正してコミットしたての、そのコードをだ、
自分があるいはとなりの席の奴が使うとして
ドキュメンテーションコメントを確認して使うのか？それは本当かい？

37 ：

開発プロセス次第かもしれんが、スクラッチ書いて、顧客に見せてフィードバックもらって、設計改善して、、
って出荷できる状態を短期に確保しながら動作して使えるコードを書き続ける現場でさ、
コメントとコードとで重複した情報なんか残してたら、修正速度の足かせにしかならんよ。
コメントとコードなんて乖離したらノイズだしな。
だったら、コードだけで伝わるようにしよーぜっ
てなると思うんだが。おもいらの現場は違うのか？

38 ：

コードの内容を素早く把握できるように
コメントを書いておこうぜってなるのが普通

39 ：

>>35
引数の制約もコード見て調べるんか？
例えばベジェ曲線を計算するメソッドが有ったとして
同一座標が重なってはいけないという制約があるとする。
それをコメントで一言
//頂点が重複する場合は例外が発生する
と書けばいいものを、
反復で変化する値を追い分岐の変化を追って
例外に至る原因となる引数を特定するのか。

40 ：

>>34
x コードを読めばわかる
o シグニチャ見ればわかる
だな。
コードコード言いすぎて一つの語を複数の意味で書きちらしたおれのミス。
複雑さを隠蔽するために書くわけだからコード本体を使用者に読ませるつもりは当然ないよ。

41 ：

「頂点が重複する場合は例外が発生するベジェ曲線を計算する関数」って
意味を表す英語の名前にしておけば良い。

42 ：

>>39
その制約を、コードのクライアントが知るべきか？その例外をクライアントが処理すべきかどうか、あたりで変えるかなあ。
つまりバグでしよ？正しいコードじゃおこんねーよ、だったら集約例外でログ吐いとこー方針でAPIには含めない。
業務仕様でしょ？だったらAPIに含める。APIへの含め方は、例外で表現するか、戻りの型？クラス？列挙型？で表現するかは、言語特性次第だな。
実運用上はコードでの表現を第一に考えて「うわーギブアップ！今の俺の実力じゃコ(現実的な時間では)コードで表現出来んわ」となったら、ションボリしながらコメントで言い訳する。で自分にがっかりするw

43 ：

そうまでして、コメントをスリムにコードでこそ語ろうぜ！という方針の意図は、DRY原則はいうまでもなく、
本当に気をつけて欲しいこと、コードでは表現出来ない設計背景、判断経緯、確実に留意すべき重大な意図が、どーでもいいコメントたちに埋れてしまわないよーに、だよ。
危険な匂いのするコードには、コメントが書かれてる、それもタップリと。
だから読み落としも防げる。そんな感じ。

44 ：

>>42
ゼロ除算と同程度の話なんだけどな。普通そんな座標は入れないし。
メソッドを呼び出す側としては当然知っておくべき制約。
普通ゼロ除算をしちゃいけないと説明されるから値を渡す側はみんな割る数に0を
渡さないよう気をつけるだろそれと同じ。

45 ：

で、どちらにしろコメントが不要になることはなく、
コメント書くならば、一箇所だけに書けばいいわけで
コメントとコードが分かれていると
同期を取らないといけなくなるから
一つにしろというのが>>6-7なわけだ。
あ、コードの中身はwikipediaの
JavaDocからの引用だからね

46 ：

0で割ったら無限大になる
ライブラリだってあるだろうさ。

47 ：

>>44
計算によっては1を渡したら0除算になる場合だってあるだろうさ。
そのことを知らせるにはコメントに書くしか無い。
コード見たって、バグかも知れないと思うだろ。

48 ：

>>47
すまんコメントが必要だとしめるつもりだったのに書き忘れた。

49 ：

ここまで例外と無関係な雑談。

50 ：

なんか勘違いしてる人がいるようだが、別にコードで全てを語ろうなんて言ってる人はいなくて
その関数が何をする関数なのかは関数名でほとんど解るようにするのがスマートという話だろ。

51 ：

そして、関数やクラスを作る人の力量は、
それを使う人が気にしなきゃいけないことがどれだけシンプルに収まってるか、に現れるので
コメントをダラダラ書いている時点で何かが間違っていると感じないといけない。
関数の（外向きの）コメントなんて、ヘッダの宣言の横に１行あるかないかで十分だと思う。

52 ：

で、関数名で分かるようにしろと言ってるだけで、
結局そもそもの問題。関数の引数とそのコメントの二箇所に
同じ名前が書いてあるのは無駄だから統一しろという
>>6-7の話をすり替えてるだけなわけだ。

53 ：

引き続き例外と関係ない話。

54 ：

>>48
コードとコメントでコメント信じるのはアホだ
コメントはあれだよ、自転車の補助輪みたいなもの。運痴のやつが、親に支えてもらう代わりに、転ばないよーにつけてる感じ？

55 ：

@throws RedundantCommentException
コメントがコード内容を繰り返すだけで冗長です。命名や設計を改善してコードの意図をシグニチャだけで表現出来るよう成長しましょう。

56 ：

@throws ExcessiveCommentException
コード総量に占めるコメントが大杉ます。読み手のことを考えることなく、自分が書きたいこと書けることを書き散らすことで、何が重要で何が些細かが伝わりにくい状況です。古い習慣を疑いコメント設計を行いましょう。

57 ：

@throws MisleadCommentException
コードとコメントが乖離しています。コメントを書くことが目的か手段かを混同し考えなしに機械作業を行うと発生する現象です。身の丈にあったコード規約を採用し、コメントがノイズにならないようにすべきです。

58 ：

>>55-57
なにwikipediaにのってるサンプルコードに
文句付けてるんだ？ 恥ずかしくないのか？

59 ：

@throws Wikipedia厨Exception
大好きなウィキペディアが批判されたと勘違いして感情的になる人間を検知しました。論理的な内容に目を向けるようにしましょう。
@see >>58

60 ：

痛いって…似たようなコメント連投するな。

61 ：

class 58=60自己弁護Exception extends InvalidAttitudeException {}

62 ：

発狂すんなよ

63 ：

掲示板 2ch = Repository.Find("例外を正しく使えない...");
try{
2ch.read();
} catch(雑談Exception e){
2ch.warn("引き続き例外と関係ない話", e);
}catch(Wikipedia厨Exception e){
2ch.warn("痛いって…似たようなコメント連投するな。", e);
} catch(発狂Exception e){
2ch.warn("発狂すんなよ", e);
}

64 ：

（　＾ω＾)ﾁｭｯﾁｭ
コメントを正しく書けないプログラマ多いね。 REM 1
http://hibari.2ch.net/test/read.cgi/prog/1306646248/

65 ：

そもそも、例外が必要なのって楽したいからだよね？面倒くさいチェック処理とか省きたいから。
なんか間違ってるか？
＃　そんな俺は例外書くことは基本的にない。

66 ：

例外は用途であって機能ではないけどな。
try-catch以外にも、GetLastErrorやらerrnoといったライブラリ、
割り込み命令で例外を処理してるし。

67 ：

>>66
> GetLastErrorやらerrnoといったライブラリ、
> 割り込み命令で例外を処理してるし。
うん、だからそういうのを一箇所にまとめられる→楽したい　ってことなんでしょ？
って思ってさ。
例外処理本来の用途って意味だと、例外が発生してもプログラム三原則に沿って
動き続けるためだろうなーっとは思ってるんだけどさ。

68 ：

楽をしたいってのは間違ってるぞ。
楽に例外処理をしたい。
こっちが正解。

69 ：

>>68
ｆｍｆｍ
なるほど、それはそうだね

70 ：

>>67
try-catchの事言ってんなら大して、例外処理箇所は変わらんぞ。
例えば、文字列を数値に変えるInteger.valueOfがあるが、
このメソッドは、値が不正なとき例外を出す。
しかし、この例外には何が原因かは情報がない。
原因が何かは、Integer.valueOfに間違った値を渡した
呼び出し元のメソッドしかしらんからな。
だから、基本的にifで戻り値調べて、どの値が間違っています
って書くのと例外処理の箇所は変わらん。
楽になるとすれば、下層のメソッドから上層のメソッドへエラーを
伝えるだけの処理が省けることと、異常のあったループなんかから
抜け出しやすい事。
まぁ、そもそもtry-catchの発端は、C++でエラー情報を戻り値で
伝えられない関数を補助するためだから。

71 ：

> このメソッドは、値が不正なとき例外を出す。
> しかし、この例外には何が原因かは情報がない。
あるぞ？
例外:
NumberFormatException - 文字列が解析可能な整数型を含まない場合

文字列が解析可能な整数型を含まないという情報がある。

72 ：

>>70
そもそも入力チェックに例外を使っているのが間違い。
例外はその名のとおり例外。
通常の処理の流れでありえない＝途中で中断すべき場合に使う物
どの値が間違っているか調べることなんかに
使うべきものじゃない。

73 ：

>>71
原因が何かってのは、幅に文字が入ってるとか、
高さに文字が入ってるとかだぞ解ってるとは思うけど。
>>72
何から入力させてんの？まさかコンソールから値を入力する事を前提にしてるわけじゃないよね。
GUIならさ、普通数値以外を入力できなくさせることができる訳じゃん。ここで数値チェックなんてそもそも
必要ないわけよ。じゃあ他に数値が入っているべき場所に文字列が入ってる状況は？
そうなるとファイルやら通信データになるわけだ。当然データ構造のパースが走る。
パース処理は浅くはない、パース途中で値が無効だと解った時のコールスタックと、
パースが崩れた原因を知っているコールスタックは距離が離れてる。
そういう場合、いちいち例外投げない数値チェックをするのは、処理が2重になる上
コールスタックのif連鎖がある分無駄でしかないんだよ。

74 ：

>>73
例外っての出してもらうもんじゃないよ。

自分がわかるんだろ？
分かるやつが、例外の中にその情報を入れて
投げるもんだ。
その結果「例外には詳細なエラー情報が含まれる」ことになる。
やっぱり例外の使い方分かってないよ。

75 ：

>>74
それはそうだよ。でもそんな話はしてない。
それは、まず例外を受け取ってからの話だ。

76 ：

君たちはちょっとアセンブラレベルから一回考え直したほうがいいです
ポリもーフィズムとか、継承なんかと並んで、例外っつうのも説明されるから
初心者が陥っちゃうところなのかもね
例外なんて、ただの1メソッド扱いでいい。　使わなくたってプログラムは完成すんのに

何をどうしたいのか具体的に言ってみ？

77 ：

>>72
中断するべきかどうかっていうのを起点にするならちゃんと判定しろって思うんだけど
どうなんだ？
例外処理って「なんか起きても動き続けるために」使うもんだと解釈してるんだけど。
＃　発想としては、ね。そりゃ書き方次第でいろいろ使えるのは分かってる。

78 ：

>>77
だから、例外の処理自体はC以前の時代からあって、
try-catch使おうが、ハンドラー使おうが、戻り値使おうが
例外処理の内容は昔と同じなんだって。

79 ：

>>78
なにについて「だから」って使ってんの？

80 ：

Begin Sub A
On Error GoTo Err
Exit Sub
Err:
End Sub

81 ：

>>77
> 例外処理って「なんか起きても動き続けるために」使うもんだと解釈してるんだけど。
例外処理は、通常の処理とは違う異常事態が起きたことを簡潔な形で伝える物。
伝えるだけ。

伝えた後動き続けるかどうかは
アプリの仕様しだい。

82 ：

それは例外処理じゃなくて例外機構だろ。

83 ：

>>81
> 例外処理は、通常の処理とは違う異常事態が起きたことを簡潔な形で伝える物。
俺が「動き続ける」といったのはもちろんその「伝えた」以降の話なんだけども、
ぶっちゃけ「なんかよく分かんないことが起きましたので処理を中断して終了」
っていうのは、バッチ的な解釈なんだよね。
オンライン（リアルタイム）の場合は止まってはいけない。できればバッチの場合
でも復帰して続ける。
銀行ATMで「すいませんがなんか想定外のことが起きたんで停止します」って
話になったら業務に支障が出るわけで。
止まっても問題ない場合は止まればいいと思うよ。でもそれは例外処理の本来
の使い方ではないかなぁと思うんだよね。

84 ：

まず、throw try catchの概念を捨てて考えたら？
例外機構のない言語で同じ事態に遭遇したらどうするか。
それが基本的な答えだよ。その答えのうち面倒な部分を例外機構が補助してくれる。
例外処理にどんな例外機構を使ってるかは重要じゃない。

85 ：

>>84
その概念を捨てて例外について騙ろうって言うのか？
お前、大丈夫か？

86 ：

>>83
想定外のことが起こったら、停止するしかない。
想定外のこと以外でも例外発生すると面倒なんだけどな。

87 ：

例外を使おうがそれ以外を使おうが
想定外のことは起きるし、その時にやりたいこともなにも変わらない。
単に例外を使えば簡単に処理がかける。

88 ：

>>85
ノイマン型コンピューターには分岐と変数となんやらかんやら・・・。
Cωで書けたプログラムがFORTRANで書けないわけじゃない。
HTML5の技術を使わずjavascriptだけで3Dグラフィックスを
書くこともできない訳じゃない。こんな感じでな。
http://jsbin.com/ubiyay/3/edit#preview
アルゴリズムがチューリング完全ならどの言語にも依存しないのと同じで
例外処理だって言語に依存しないし、十分語れる。
例外情報が必要とかいうなら、staticな共用データ(共用体)に格納すれば
例外機構の無い他の言語でも用意できるし重要じゃない。

89 ：

問題は、想定内の事象での例外だな。
まさにスレタイの通りではあるんだが。

90 ：

>>88
いや残念ながら俺は例外処理必須と考えてるわけではない。
初発は>>65だ。
で、まぁ例外処理だって言語に依存しないっていうのはまぁ分かるし、
十分語れるならそれをかたってくれい。

91 ：

続き
ただ、俺が>>85で言いたかったのは>>1を無視してまで騙る必要がこのスレに
あるのかってこと。

92 ：

この板は、相変わらずだな。
例外がCPUとOSに依存しているのをいまだ、まともに理解出来ている人間がいない。
例外はCPUの割り込み処理だと分かっているのか？
その割り込み処理を、個々のプログラムで制御を許しているのは
OSがマルチタスクだと理解できているのか？
技術者のくせに、CPUやOSの仕組みをしらない奴が多すぎ。

93 ：

お前は口だけでOSを作る上で一番面倒なことは何か理解していないようでしたが？

94 ：

>>93
俺は初レスだ。

95 ：

だから何。
あんたはトランジスタを、電子の動きを、半導体の作り方を理解して、コンピュータ使ってるのか？
下のレイヤを抽象化するのがエンジニアリングであって、下のレイヤを全部理解してなければ
わからない、と主張するのはバカのすることだぞ。

96 ：

>>95
お前は頭悪いな。自分の文書に違和感は無いのか？
>あんたはトランジスタを、電子の動きを、半導体の作り方を理解して、コンピュータ使ってるのか？
”電子の動き”って、中学で習うだろう、義務教育を受けていれば分かることだが。
それにパッケージになっているLSI（CPU)とトランジスタを比べてどうするだ？（半導体の作り方ってｗ）
>下のレイヤを抽象化するのがエンジニアリングであって、下のレイヤを全部理解してなければ
>わからない、と主張するのはバカのすることだぞ。
まったく分からん、何が書きたいんだ。”下のレイヤ”・”下のレイヤ”って？OSやハードのことか？
抽象化って、理解出来ていないものを抽象化出来るのか？それはただ単に知らないだけだ。
言葉遊びならとりつくろえても技術者としては駄目だな。
それに、そもそも技術者とは抽象的なものを具象化するものだろう。
別に全部理解しろとは言ってないが例外の話なら例外ぐらいは理解して話せ。

97 ：

フリップフロップ位理解したほうがいかなと、トイレで寝ながら書き込んでいる。

98 ：

どこまで理解してたら例外を理解してることになんの？

99 ：

>>92
それは例外実装のひとつだろ。
実装であって目的じゃないし、本質じゃない。
・例外実装の種類
　・ハードウェア例外機構
　　・CPU例外
　　　・ソフトで検知できない異常をソフトに通知する
　　　・基本的に割り込み用途の極一部でしかない
　・ソフトウェア例外機構
　　・OS例外
　　　・アウトプロセスの異常を通知する
　　・ライブラリ例外
　　　・結果が得られなかった事を通知する
ハードウェア例外機構 implements 例外機構;
ソフトウェア例外機構 implements 例外機構;
そもそも根底にあるのはタダの例外機構。
機構自体は、何ら例外の主体ではない。

100 ：

>>99
またアホなことを。
ハードウェア例外だろうがソフトウェア例外だろうが
割り込み処理で実行しているのが分からないのか？
根本的に割り込み処理が分かってないから
そんな恥ずかしいことを堂々と書けるんだろうな。
お前の書いた例外処理をだれが処理しているんだ？
CPU以外に誰が処理してくれるんだ？
例外処理は、ノイマン型CPUなのに、なぜ急に処理の順番が変更できるんだ？
頭を使って考えろ。

101 ：

ハードウェア例外とソフトウェア例外以外の
例外もあるよ。ただのジャンプで実装された例外。

102 ：

例外処理ってのは、割り込み処理から復帰してから動くコードだよ。
割り込み自体は単に処理の順番を入れ替える地点だけに過ぎない。

103 ：

こういうバカって幸せなんだろうなぁ。うらやましい。

104 ：

> 例外処理は、ノイマン型CPUなのに、なぜ急に処理の順番が変更できるんだ？
処理の順番が変更できないと、分岐もできないだろー。
割り込みと例外の区別が付いていないのかなー？

105 ：

例えばゼロ除算とかは、プロセッサの例外をトラップして処理系レベルの例外にするわけだけど、
処理系の発生させる例外はそういうものばかりじゃないからな。
たとえば、システムコールがエラーを返して終了したらIOエクセプション、とかいう処理系は
よくあるし、その実装にわざわざプロセッサ例外を起こしてそれをトラップして、なんて、
普通はやらない。
プロセッサレベルを知ってる俺様無双、って威張りたいだけのバカでしょ。

106 ：

>>100
お前割り込みの意味しらねぇだろ。
割り込みっつうのは、そもそも割り込みコントローラーが能動的に
割り込み信号をCPUに送りつけ、割り込みベクタを実行させ
ポーリングを排除する。
ソフトウェア例外は、ただの分岐。全く割り込み関係ない。
jgeとかjmpとかintやスタブじゃない命令は割り込みとは言わない。

107 ：

>>101-106
何を必死になっているんだ。哀れすぎるぞ。
>>101
具体的には？　言語はなんだ？
>>102
割り込み処理が発生しないと例外処理が出来ないのは納得するんだな。
割り込み処理は、誰が処理をするのか分かるか？
例外から発生した割り込み処理をプログラムが直接受け取るとでも思っているのか？
本当に割り込み処理が分かっていないんだな。
>>104
>処理の順番が変更できないと、分岐もできないだろー。
アホｗ　分岐はジャンプ命令で書いてあるから分岐するんだろうが、それがノイマン型だ。
トラップ部分全てにジャンプ命令が書かれているのか？
ジャンプ命令が無いのになぜ処理の順番が変わるのか考えろ。
>>105
>たとえば、システムコールがエラーを返して終了したらIOエクセプション、とかいう処理系は
>よくあるし、その実装にわざわざプロセッサ例外を起こしてそれをトラップして、なんて、
>普通はやらない。
疲れるなアホが多すぎて、じゃなぜ例外処理に処理が移動するんだ？
割り込み処理が発生するから例外処理に移動するんだろうが。
お前の書いたプログラムをアセンブラで見てみろよ。
「システムコールがエラー」で例外にジャンプする命令が書かれているか？
>>106
>ソフトウェア例外は、ただの分岐。全く割り込み関係ない。
アホｗ　自分が書いたプログラムも読めないのか分岐命令が書かれているか？

108 ：

>>106
割り込みについてはそうなんだろうけど、ここで言ってる例外がなにを
さしてるみんなが話してるのかってことを度外視してまで続ける必要が
あるのかって部分で疑問だわ

109 ：

setjmp/jongjmpで実装した例外処理とか知らないんだな、このバカは

110 ：

魔法みたいな例外処理使ってるらしい...

111 ：

>>109
それは例外機構じゃないだろう。

112 ：

>>107
>アホｗ　自分が書いたプログラムも読めないのか分岐命令が書かれているか？
書かれてるけど？何が言いたい？
まぁ、その付近にはシステムコールの割り込みが存在する事もあるけど
それはシステムコール用だし関係ない話。そもそもプロセスを跨いだ例外で無い限り
割り込み命令やスタブに出くわす事もない。だいたいWindowsじゃ割り込み命令(int)の
殆どはリングプロテクトの中じゃないと使えねぇしな。基本的に目にするのはスタブの割り込みだらけ。

113 ：

ソースコード上の話してるだけだから、そういう事いってもわからないんだよ

114 ：

>>107は自分の書いたコードがどうコンパイルされてるか
アセンブラで確認することもしないんだろうなぁ。

115 ：

>>107
ほい。G++のtry catchのランタイム実装コード。
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/unwind-sjlj.c?rev=1.21&content-type=text/x-cvsweb-markup
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/unwind.inc?rev=1.12&content-type=text/x-cvsweb-markup
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc%2b%2b-v3/libsupc%2b%2b/eh_alloc.cc?rev=1.13&content-type=text/x-cvsweb-markup
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc%2b%2b-v3/libsupc%2b%2b/eh_throw.cc?rev=1.11&content-type=text/x-cvsweb-markup
割り込みが存在すんのは、mallocとstd::terminate内部の呼び出しぐらい。
あとはスタック操作とか普通のライブラリのコードで書かれてる。

116 ：

沈黙したな。ageてみるか。

117 ：

>>112-115
まったくアセンブラも読めないのか、話にならない。
try-catchの間で、catchにジャンプするJxxxのジャンプ命令は書かれていないだろう。
どうやって例外処理が呼び出されているか考えろ。

118 ：

>>115読めよ。読める知識もないのに語ってんのかアホ。

119 ：

>>118
人の書いたソースより自分の書いたプログラムのアセンブラを読めよ。
すぐに分かるだろ。　読めないのか？

120 ：

あのな。try,catch,throwってのは、本当に>>115の呼び出しに置き換えられてるだけなの。解る？
アセンブリ化したコード読んでも、>>115のコードの呼び出しが書いてあるだけ。
わざわざアセンブリで読む意味がない。

121 ：

>>92
半年経っても理解できなかったのか。悲しいな。
http://logsoku.com/thread/hibari.2ch.net/prog/1296098340/285-
時間の無駄だから、みんなスルーして欲しいな。

122 ：

>>120
まったく、なんでアセンブラを読まないのか。読めば解決するだろう。
じゃ、簡単な質問をする。
マルチタスクOSのメモリーは、OSやいろいろなプログラムが使っている。（これは理解できるだろう？）
自分の作ったプログラムでオブジェクトのメソッドを呼び出そうとする。
しかし、そのオブジェクトは不正な値が入っていたとする。（他のOSやプログラムが使っているアドレスを指している）
この時例外が発生するが、他のプログラムやOSの例外処理が動かなくて
自分のプログラムの例外処理が動くのは何故だ？
>あのな。try,catch,throwってのは、本当に>>115の呼び出しに置き換えられてるだけなの。解る？
その理屈だと、どうなる？

123 ：

> しかし、そのオブジェクトは不正な値が入っていたとする。（他のOSやプログラムが使っているアドレスを指している）
> この時例外が発生するが、
例外が発生するかどうかは、OSやCPUのメモリ保護機能によって決まる。
発生するとは限らない。
馬鹿か。
> 他のプログラムやOSの例外処理が動かなくて
ＯＳやＣＰＵのメモリ保護機能によって、OSの例外処理が働く場合もある。
馬鹿か。
> 自分のプログラムの例外処理が動くのは何故だ？
馬鹿か。
> その理屈だと、どうなる？
>>115のアセンブラの動きが答えだろ。

124 ：

>>122
構造化例外の事を言いたいのか？
普通 _set_se_translator()を呼び出し、シグナルを言語仕様のthrow文に変換するコードを渡す。
基本的にOSからシグナルとして伝えられる例外と言語が持つ例外は別物。
暗黙だろうが明示的だろうが何らかのマッピングが必要になる。
まぁ、Javaなんかはシステムレベルの例外は、ランタイムでフックしてthrowに置き換えたり、
VMでリソース監視してVMがthrowしたりするけど、割り込みとは世界が別。

125 ：

釣れたね。よかったね。
これくらいでもうやめてくれない？つまんないからさ。

126 ：

>>123
>例外が発生するかどうかは、OSやCPUのメモリ保護機能によって決まる。
>発生するとは限らない。
お前、自分で書いていて矛盾を感じないのか？
例外が発生するときはOSやCPUによって決まる書いているんだぞ。
意味がわからん。

127 ：

>>126
中途半端に抜き出すな。
俺が言っているのは、
> しかし、そのオブジェクトは不正な値が入っていたとする。（他のOSやプログラムが使っているアドレスを指している）
> この時例外が発生するが、
つまり、他のＯＳやプログラムが使っているアドレスを差したときに例外が発生するかどうかの話をしている。これはOSやCPUによって違う。
たとえばulinuxやMS-DOSとかだと他のプログラムが使っているアドレスを差したとしても例外は発生しない。
なにも矛盾しているところはない。また中途半端に抜き出されたくないから、改行少なく書いてみたよｗ

128 ：

お前ら誰がどの考えなんだ。
１．例外はOS・CPUに依存する。
２．例外はOS・CPUに依存しない。
３．OS・CPUに依存する例外と、依存しない例外がある。

129 ：

× １．例外はOS・CPUに依存する。
○ １．他のプロセスのアドレスを参照することで発生する例外はOS・CPUに依存する。
自分の言った言葉ぐらい
責任をもて

130 ：

>>127
>つまり、他のＯＳやプログラムが使っているアドレスを差したときに例外が発生するかどうかの話をしている。これはOSやCPUによって違う。
>たとえばulinuxやMS-DOSとかだと他のプログラムが使っているアドレスを差したとしても例外は発生しない。
だから、お前はバカなの？　
ulinuxやMS-DOSでは例外処理が発生しないのはOSによるものだろう。
>>129
お前は何が言いたいんだ？　３と言う事じゃないのか？
お前は本当に意味が分からん、上から読んで整理してからこい。

131 ：

ulinuxやMS-DOSでは例外は使えないの？

132 ：

わざとなのか知らないが、アドレス違反などの CPU 例外と、
Windows 構造化例外のような OS の例外と、 C++ はじめ
プログラミング言語の例外とをごっちゃにしたまま話をしたのでは
わけがわからない。

133 ：

ごっちゃまぜ以前に、
すごく狭い自分の知識と視野でしか話すことができないバカが、
半年以上ずっと頑張ってるだけだから。
こんなバカが他で暴れたり仕事したりするのは社会に有害だから、
ここでしっかり構ってやんないとw

134 ：

>>132
誰がごちゃ混ぜ話しているんだ？
まったく、例外はCPU、OSに依存しないと書いたかと思えば
今度はCPU、OSに依存すると書くしわけが分からん。
誰か俺の書いた>>92がどう間違っているのかを、はっきりかいてみろよ。
言っとくが一部の奴が言っている、一部言語に実装されている
擬似例外は、例外機構じゃない、擬似は擬似だ。
正式な例外みたいに言うのは間違っている。

135 ：

> OSがマルチタスクだと理解できているのか？
OSがマルチタスクだと理解していることがどう例外と関係するんだか。
> 技術者のくせに、CPUやOSの仕組みをしらない奴が多すぎ。
それがどう例外と関係あるんだか。
例外の仕組みをしらないのはおまえ自身だろ。
> 言っとくが一部の奴が言っている、一部言語に実装されている
> 擬似例外は、例外機構じゃない、擬似は擬似だ。
> 正式な例外みたいに言うのは間違っている。
俺様定義を振り回したってだれもそんなもん知らんわ。

136 ：

>俺様定義を振り回したってだれもそんなもん知らんわ。
一部言語にしか実装されていない擬似例外を
一般的な例外と言う方が”俺様定義”だと思うが。

137 ：

>>136
で、その俺様定義を「そーですね」って言ってあげれば立ち去ってくれるの？
すっごい粘着しそうなんですけど
ここまで粘着するからには

138 ：

>>135,137
まったく自分だけ、かなり的外れ事を言っているのにきずかないのか？
俺以外の奴もこう言っているぞ。(>>127,123)
>OSがマルチタスクだと理解していることがどう例外と関係するんだか。
>たとえばulinuxやMS-DOSとかだと他のプログラムが使っているアドレスを差したとしても例外は発生しない。(>>127)
Windows7とulinuxやMS-DOSの違いは？
あと、>ＯＳやＣＰＵのメモリ保護機能によって、OSの例外処理が働く場合もある。(>>123)
のメモリ保護機能ってどんな時に必要になる？
>> 技術者のくせに、CPUやOSの仕組みをしらない奴が多すぎ。
>それがどう例外と関係あるんだか。
>これはOSやCPUによって違う。(>>127)
お前が割り込むと、話がめちゃくちゃになる。　粘着するな。

139 ：

それが目的ですからw

140 ：

> 自分だけ、かなり的外れ事を言っている
おまえもなんだけどなw
一生きづかないだろうけどw

141 ：

>>139
>それが目的ですからw
嘘つけ、本気で思っていたんだろうが。
それ言い訳、哀れすぎるぞ。
>>140
誤字ぐらいで揚げ足をとるか情けない。お前のも
>おまえもなんだけどなw
おまえ"も"って、自分が「的外れ」だと自覚はあるんだな。

142 ：

×それ言い訳
○その言い訳

143 ：

>>134
> 誰か俺の書いた>>92がどう間違っているのかを、はっきりかいてみろよ。
「例外」の定義が一般的でない俺様定義になっているので、はっきりしません。
はっきりしたいのであれば、「例外」を「CPUの例外」「OSの例外」「言語の例外」あたりに
分類して書き直してください。

144 ：

「言語の例外」の話でしょ、ここでは
「CPUの例外」「OSの例外」が「言語の例外」に含まれてるから、話がややこしくなってる
「CPUの例外」「OSの例外」を除外した「言語の例外」の話だと自分的には面白くないだけどね

145 ：

「自分の関わった領域における例外」じゃね？
OSとかCPU(ハード)の例外は別のモノ、つまり「自分の関わらない領域からの例外(≒割り込み)」
後者をどうやるか(回避するか)ってのは確かに面白いね。
人の行う例外入力に対する処理もそれかな？　このスレとは若干というかかなりかけ離れる気がするけどさ。
だって、例外を“使う”ってタイトルからすれば命令とか機構をどう使うかって事だし、
CPUとかOSの例外をどうするかっていうと“どう処理するか”ってなるから、例外を“使う”と言う表現はちと違うね。
どっちも意義のある議論項目には違いないと思うけど。

146 ：

>>136
一部OSやCPUにしか実装されていないものを「一般的な例外」と主張するのは俺様定義でしかないなｗ

147 ：

>>144
いちいち○○の例外とかうざい。
全部例外でいい。
それで勘違いするやつが馬鹿なのだ。

148 ：

「一部OSやCPUにしか実装されていないものを「一般的な例外」と主張するのは俺様定義でしかないなｗ 」
という定義について意義がある人はいませんか？
いないなら、この定義を一般的なものとしますよ。

149 ：

つまらん。

150 ：

つまらんというのも
俺俺定義ですね？

151 ：

ず〜〜〜〜〜〜〜〜〜と、つまらん話が続いて.......

152 ：

でも、それでもこのスレを見てしまうのです。僕は病気でしょうか？

153 ：

結局>>92は何が言いたかったんだ？
「お前等バカばっか!!俺天才!!悔しがれよクズがっ」とでも言って
自尊心を満たしたかっただけなのか？まぁ、今のところそうとしか思えない発言だらけだが。
それとも、万が一かもしれんが、もしかしたら、ひたすら割り込みに拘ることによって、
何かが劇的に改善する方法論を知ってるのか。もし、そうならダラダラ押し問答するより
その貴重な方法論をとっとと語ってほしいもんだ。

154 ：

とまあ一番むかついた人にレスしたのであった。

155 ：

>>143,144
お前ら当然のように分類を決めているが、だれがその分類で正しいと言ったんだ？
「CPUの例外」「OSの例外」「言語の例外」の具体的な例外は？
この例外をその分類で表してくれ。足りなければ追加してくれ。
・徐算エラー
・配列境界違反
・無効命令
・スタック例外
・一般保護例外
お前らの言っている分類ってなんだ？

156 ：

IOException も知らずにこれだけ大威張りしてきたとはなw

157 ：

また来た・・・。

158 ：

>>155
・配列境界違反
・スタック例外
程度が知れるなw

159 ：

うふふぅ

160 ：

上から目線で話されても...

161 ：

>>155　そんな事はどうでもいいから、どういうメリットが
ある事を言いたいのか書けよ。

162 ：

OSもCPUも理解してるはずのおまえが、分類できないわけがない。
OSもCPUも理解してるってのが大嘘でした、と大声で宣言しちゃったわけだ（核火暴笑）。

163 ：

> （核火暴笑)
ってなに？

164 ：

若いな

165 ：

>>155
0除算ひとつとってもプロセッサが例外を発生させることもあればソフトウェアが
検知して言語の例外を発生させることもあるわけで、要因に対して分類が１対１で
対応するわけでもない。
IA-32 の Divide Error をどれに分類するか、と具体的に言ってもらえれば、
それは「CPU例外」であるなどと分類を示すことができる。

166 ：

「CPU例外」ってのは、バグ潰すのに便利だったんだけど
例外ってのがバグ隠し？みたいな使い方する（される）のがなんとなく

167 ：

なんだ、また例外処理機構ｗのやつが出たのか。
こんどは32bitだとか8086より先とか言わんのか？

168 ：

そうやって排除するのか？

169 ：

当然。

170 ：

この業界の性格丸出しだね

171 ：

バカを排除するのに性格もクソもあるか。

172 ：

そうやって、優越感に浸るのも...

173 ：

やっぱりな、結局誰一人分類出来なかったな。
自分達が分類出来ないものを俺に分類して説明しろだと！
知識もない、いい加減な事しか言わない最低な奴らの集まりか。
>>156
IOExceptionは「CPUの例外」「OSの例外」「言語の例外」でどれだ？
>>158
>[割り込みだと両方セグメンテーション違反]
>・配列境界違反
>・スタック例外
>程度が知れるなw
俺には、お前の程度が良く分かるが。
OSレベルの知識しかないんだな。
>両方セグメンテーション違反
馬鹿か？詳細に分類したものを大雑把にいってどうする。
それなら全て例外と分類すればいいだろう。
>>162
なんでお前らが勝手に決めた分類を
俺が出来ないといけないんだ？　お前は頭おかしいだろう。
>>165
> 0除算ひとつとってもプロセッサが例外を発生させることもあればソフトウェアが
>検知して言語の例外を発生させることもある
よくそんな嘘を平気で書けるな。
”ソフトウェアが検知して”ってどんな仕組みで感知してるんだ？
具体的に説明してくれ。　まっ逃げると思うが。

174 ：

>>173
> ”ソフトウェアが検知して”ってどんな仕組みで感知してるんだ？
仕組みというほどのこともない。
int f(int a, int b)
{
  if (b == 0)
    throw division_by_zero(a, b);
  return a / b;
}

175 ：

div(a, b){
if(b == 0){
throw new hoge();
}
...
}

176 ：

もしかして、throwで例外を発生できることをしらない？

177 ：

>>173
> やっぱりな、結局誰一人分類出来なかったな。
お前のお題が曖昧すぎるからだろ。 >165 の言うとおり。

178 ：

> やっぱりな、結局誰一人分類出来なかったな。
おまえ一人がおかしい、という可能性をなぜ考えない。
> 自分達が分類出来ないものを俺に分類して説明しろだと！
おまえ、自分はすべてわかってる、他人はすべてバカ、って態度だろ？
それを裏付けるものがなにもねぇじゃねぇか。
> 知識もない、いい加減な事しか言わない最低な奴らの集まりか。
おまえこそが、知識もない、いい加減な事しか言わない最低な奴じゃねぇか。
> お前らが勝手に決めた分類
とか言うが。
> 擬似例外は、例外機構じゃない、擬似は擬似だ。
勝手な分類をはじめたのはおまえじゃないか。

179 ：

>>174-176
それは単に例外を発生させているだけ。
それなら、チェックしないで>return a / b;
を実行した場合>return a / b;が検知場所か？
どこで検知して、どう例外処理を実行させているかを聞いているが。

180 ：

はぁ？

181 ：

もうスルーしようぜ、いい加減に。

182 ：

割り込みスレでもCPU例外スレでも立てて、そっちでやってくれよ。

183 ：

>>179
お前の中では「チェックする」と「検知する」が別物で、
「例外を発生させる」ことと「例外処理を実行させる」ことが異なるのか？
微妙すぎてわからんｗ

184 ：

>>179
> どこで検知して
条件文で
> どう例外処理を実行させているかを聞いているが。
その言語に備わっている仕組みで。
CPUの割り込みも、OSの例外も出てくる幕はない。

185 ：

まったく、じゃ簡単に書く。
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
お前は特によくアセンブラを追いかけろ。

186 ：

>>185
int f(int a, int b)
{
return a / b;
}
もしかして、この場合も事前にゼロチェックしてるとおもってるのか？

187 ：

例外を発生させることができるのはCPUだけ。
という宗教です。

188 ：

このスレ定期的に盛り上がるな

189 ：

割り込みと例外の区別ぐらいつけろよｗ
0除算とかそういうのは割り込みであって例外ではない。
割り込みを復旧させるときに例外に変換することはある。
だが例外そのものは割り込みではなく
CPUが発生させる物。

190 ：

>>185
b が 0 の場合、前者は C++ の規格に沿って例外処理が実行される。
同じ条件で、後者は未定義動作となるので何がどうなるとも言えない。
プログラムが止まるかもしれないし、 0 が返されるかもしれないし
1 が返されるかもしれないし、前者とまったく同じ動作になるかもしれない。

191 ：

>>189
CPU の割り込みと例外の区別は CPU ごとに違うので、 CPU を
特定してからじゃないとなんとも言えない。たとえば ARM あたりだと
「割り込み⊂例外」という扱いだったりする。

192 ：

割り込みに性質として、なるべく早く割り込み処理を
終わらせるというものがあるが、
その性質を考えれば、例外とは別物だって分かるだろ。
割り込みは、システム全体から見た他の処理を中断させることになり、
また他の割り込みを遮ることがあるから
なるべく早く復帰しないといけない。
だが例外は違う。ゆっくりとエラー処理をすれば良い。
基本的に該当プロセスで発生した例外は、システム内の
他のプロセスに影響を与えることがない。

193 ：

別に架空の話をしているんじゃなくて
現実に動いているものの話なんだから
動かせば直ぐにわかる問題じゃないのか？

194 ：

ここ隔離スレだろw
隔離スレが隔離スレとして機能してるんだから、正常進行じゃないか。
>>192
あー。OSの設計とか次第だけど、割込みサービスルーチンではフラグ立てるか
カウンタをアップするだけで、必要な処理は別に起動したりとかするよね。

195 ：

例えばWindowsの場合
int f(int a, int b)
{
if (b == 0)
　 throw division_by_zero(a, b);
return a / b;
}
例外を発生(throw)させると、WinAPIのRaiseExceptionが呼ばれ
割り込み処理(INT 2Eh)が走る。
int f(int a, int b)
{
return a / b;
}
徐算エラーで割り込み処理(INT 00h)が走る。

196 ：

>>195
> 例外を発生(throw)させると、WinAPIのRaiseExceptionが呼ばれ
> 割り込み処理(INT 2Eh)が走る。
それ、 VC++ で /EHa を指定したとき限定の話だよね？
http://msdn.microsoft.com/ja-jp/library/1deeycx5.aspx

197 ：

なんだ。古い VC++ しか知らなかったのか。そうかそうか。

198 ：

割り込みはハードウェア的な話（ソフトウェア的に擬似的に発生するものを含める）
システムワイドに発生するものなので、プロセス事の割り込みという考え方はない。
例外は基本的にそのプロセス限定で発生する。
他のプロセスは全く感知されない。
このスレで話しているのは、後者の例外。
プロセス内で完結するもので、それ以外の話は無関係。

199 ：

>>155
純粋な機械レベルでの分類
CPUの例外
　算術エラー(SIGFPE)
　　・徐算エラー(VM)
　セグメンテーション違反(SIGSEGV)
　　・配列境界違反(VM)
　　・スタック例外(VM)
　　・一般保護例外(OSまたはVM)
　不正命令(SIGILL)
　　・一般保護例外(OSまたはVM)
　　・無効命令(OSまたはVM)
※CPUから取り出せる例外はこの3種類だけ。

200 ：

>>199
SIGBUS は違うの？

201 ：

>>195　だからさぁ何が言いたいの？例外は割り込みだけで、ほかは擬似例外と呼べっつう
言葉遊びがしたいだけなの？

202 ：

>>200
おおそうだね。一般保護例外はと無効命令は(SIGBUS)にも含まれるね。
抜けてたわ。

203 ：

>>195
INT　2EHはカーネルモードへの移行。所謂スタブと同じ話で
例外とは関係ない。例外に限らずAPIを呼び出しカーネルモードに行く場合は呼び出される。
INT 00は割り込みハンドラを明示的に呼び出す場合に使うもので、除算時にソフトに明示的に
呼ばれる事は無い。除算時はCPUからINT 00に相当する割り込みが発生するだけ。
それがSIGFPE。

204 ：

>>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 ：

えーと、このスレでは、
OSが捉えて処理する部分は無関係です。
OSが処理して各プロセスに振り分け
その言語の例外型（JavaならException）に
変換されてからが話の対象です。
INT xxの話で説明するなら、C++の文法でINT xxという
命令はありません。（インラインアセンブラは当然除く）
だからこの部分はC++の話としては対象外です。
また、INT xxが発行されてから、プロセスが直接処理をもらうことはありません。
まずOSが処理します。この部分はC++言語の範囲の処理ではないので
このスレの対象外です。
色々と処理された結果、C++のExceptionとなってからが話の対象です。

206 ：

割込みと例外の区別が付いていない奴が騒いでるだけだろ。
割込みの話をしたいのなら、割込みを正しく使えないプログラマ多いね。スレで。

207 ：

>>205-206
わかった、俺も本当は例外が割り込みだから
例外はどうあるべきかを話したかったが
もう俺は書き込まない。
本質を無視して、目先の事だけを話してくれ。

208 ：

「本質」という言葉を使う奴の99%は「俺様の定義する」である件

209 ：

やっといなくなるのか。よかったよかった。

210 ：

>>205
CPUの例外がJavaやC++の例外に変換されるみたいな言い方だけど、
実際はそんなことは稀なんじゃないの？
まったく関係ないことのほうが多いでしょ。

211 ：

またお前かｗなんでこのスレでの例外は言語の機能だと何度言えば…
で、８０８６より先の話はどーしたのよ。

212 ：

また半年ぐらいしたら現れるんじゃねーの

213 ：

>>210
そこそこはあるよ。いちいち割り算の度にjzとかアセンブリ命令入れてたら非効率だからね。
>>199 に分類されてるものは、インタプリタやVMベースだと言語の例外機構に変換されてんじゃない？
まぁ、C++の場合はハードに依存するマッピングは自分でヤレがセオリーなんだろうけど。

214 ：

>>210
こんなものがあった、割り込みと例外について書いてある １４３ページから
http://books.google.co.jp/books?id=hsb0UKJWQs8C&pg=PA152&dq=%E5%89%B2%E3%82%8A%E8%BE%BC%E3%81%BF%E3%81%A8%E4%BE%8B%E5%A4%96&hl=ja&ei=ta4PTvWEDuqimQXJ_eDEDg&sa=X&oi=book_result&ct=result

215 ：

おー…伸びてると思って覗いてみればすごい恥ずかしい奴がいるな…

216 ：

>>214
読んだらわかったわ、誰が馬鹿かがｗ
９２は”馬の耳に念仏”のことわざを覚えたほうがいいぞｗ
家畜になにを期待しているんだｗ

217 ：

>>214
でも、そのLinuxをC++で作るときの例外はどうするの？

218 ：

たとえばIOの例外についてだけど
例外を正しく使えないプログラマって、
selectを使いこなせないとかそういうこと？

219 ：

select の exception って、例外つーより OOB 食らった時じゃなかったっけ
socket 関連エラー拾えない実装があったような…

220 ：

俺はもう少し９２の話が聞きたかった
痛い奴はR

221 ：

じゃ、92と語るスレでも立てればいいじゃん。

222 ：

92は例外がどう実装されてるかという話ばかりで、
例外をどう使うかには興味がないみたいだけど。

223 ：

>>92
それは例外処理の一種あって全てじゃないんだがｗ
キミらが好きなVBや昔のBASICにも例外処理があってだな、
ネットに転がってる例外処理の解説記事はだな、
例外なく間違いなく間違っているとう事実だ。ｗ

224 ：

最後の「本質」が何かじゃんｗ
それより俺も、痛い奴にはRほしいわｗ　じゃま

225 ：

以下、自演レスでお送りします。

226 ：

ばーか、他人だよｗ　被害妄想乙ｗ

227 ：

どーでもいいけど、例外を正しく使えっていう表現が変だろｗ
例外が起きないようにプログラムを組やがれｗ

228 ：

>>224
92は本質じゃなくて、実装について語りたがってたみたいだけどね。

229 ：

>>223
>昔のBASICにも例外処理があって
On Errorのことか？　それは例外処理じゃないぞ
例外はfinally機能が大事だ

230 ：

何この屑コテ

231 ：

にわかなんで214の内容とか理解はしてないけれど
結局92は、実装レベルの視点でみて、何を問題視してたのかがよくわからん。
究極的にどのような問題があるから、実装レベルでの理解が必要だって話なんだろ。
なんつーか、お前らそんなことも知らないのか馬鹿だろ俺は知ってるぞ
っていう事ばっかで、どのレスにも中身がない感。

232 ：

>>227
そういう視点でしか見れない人はマには向いてない。

233 ：

実装こそ本質、と思ってる奴は結構いるよな
下手をすると規格なんて飾りです、とか本気で言い出すw

234 ：

規格なんて飾り

235 ：

構造化想定外処理
try {
　原発運用();
} catch( 想定外 s ) {
　// NOP
}

236 ：

>>94の主張が嘘じゃないなら>>121とは別人なんだろうけど、
121にある過去スレの主張してた内容で見たら、結局は趣味の話。
俺は業務エラーで割り込みなんて気に食わないからよろしくないと思う。って感じの結論になるような。
まぁ、本質()の話題はもういいわな。その部分の理解は多くの場合必須じゃないし。
昨今の職業マのレベルで考えたら、勉強にかかる時間の割りにメリットはあまりないから、
興味がある人が自分で理解すればいいと思うレベルの話で、このスレの目的とは違うでそ。

237 ：

正しく使えない人が多い一番の理由って、
　例外==エラー
という認識しかしてないからじゃないかなって思う。
例外エラーとか、言いたい事はわかるんだけど、
よく考えるとなんか変な気分になる単語みかけることもよくあるし。

238 ：

>>229
> On Errorのことか？　それは例外処理じゃないぞ
> 例外はfinally機能が大事だ
catchじゃないのか？
finallyはなくてもcatchがあれば
finallyと同じことが実装可能だし。

239 ：

unwind-protect

240 ：

>>229
いや例外処理だぞ。
try catch型例外機構じゃないだけで。
例外機構によって例外処理じゃないと言い始めたら >>92　と同類。

241 ：

>>214
それ、210と何か関係あるの？
CPUの例外がLinuxではシグナルに変換されてプロセスに通知される、って話だよね？
WindowsのSEHでもそうだけど、そこから先でさらに言語の例外に変換されることが
あるかどうかって話でしょ210は。

242 ：

普通にあるだろ。0除算とか。

243 ：

>>240
俺もfinallyがないのは例外じゃないと思うな
それならただのエラー処理だろう、名前もOn Errorだし
俺は>>214よんだから92は間違ってはいないと思っている。
92がいなくなるより、240みたいに決め付ける奴にいなくなってほしい。

244 ：

>>237の言っていることが正解だと思う。

245 ：

>>243
> 俺は>>214よんだから92は間違ってはいないと思っている。
さすがにそれは無い。
LinuxのシグナルやWindowsのSEHなど（OSの例外）がCPUの例外を
プロセスに配信するだけのものがほとんどで関連性が強いのは
認めるが、このスレの主題である言語レベルの例外がそれらに
依存するなどということは無い。
もともと>>92の言う「例外」が「CPUの例外」や「OSの例外」を
指していて「言語の例外」を指していないのなら内容は間違って
いないと言えるかもしれないが、それをこのスレで偉そうに言うこと
自体が間違っている。

246 ：

>>214は"CPUの例外"の扱いについて書いてあるだけ。
何で、「CPU割り込み例外 = 例外」って書いてるやつの肯定になるんだよ。
CPU割り込み例外も例外の一種だから忘れるなというならわかるけど。
てか >>243 = >>92 なんじゃないか？

247 ：

そうか？214を読むと他の奴らが言っていることが間違っていたと思えるが。

248 ：

>>229
finally無くてもデストラクタついてりゃ済むじゃん。
デストラクタ無くても.net環境とかRubyとかデストラクタ相当の
ブロックスコープがあるし。

249 ：

>>247 >>214のどのあたりに感化されたの？
上のほうで割り込みベクタとか、スタブとか言って>>92と
応戦してる人はこの内容知ってて話してるようだけど。

250 ：

>>248
はっ？

251 ：

>>247 おかしいな、俺には見えない何かを読んでいるようだ。

252 ：

>>248
例外が発生したらオブジェクトを破棄するの？

253 ：

>>252 別に破壊する必要ないけど？
それと、finallyは例外発生の有無に関係ないでしょ？

254 ：

>>249
例外がCPUとOSに依存しているところ。
スタブはOSどまりでしょう。

255 ：

>>254
９２はスタブが間違っていると書いているか？

256 ：

例外と、例外処理と、例外機構をごっちゃにして例外と呼ぶのをどうにかしてくれんか？
アセンブリをアセンブラでアセンブルするのに。
アセンブリを書くことをアセンブラを書くっていってるぐらい変。ていうか分かりづらい。
そりゃアセンブリの事を聞きかじったヤツがアセンブラ、アセンブラって言ってんのは分かるけど、
アセンブラの設定までしなきゃならん環境でアセンブリをアセンブラと言われちゃなんの事かわからなくなる。
例外についてもおんなじだから。頼むから書き分けてくれ。
ちゃんとExceptionとException handling、Exception mechanismで別れてんだから。

257 ：

>>253
デストラクタはいく動かすの？

258 ：

>>254 やっぱり >>92 か。 >>214は"CPUの例外"で
例外の全てについて書いてる訳じゃないって何度言われ手も >>92 みたいに解らないようだ。

259 ：

>>257
finallyと同じタイミング。
RAIIをはじめとして、オブジェクトの破棄だけに使うもんじゃない。

260 ：

CPUで発生した割込みは >>214の機構を使って各プロセスに通知されるけど
それと言語における例外は別の話だからなぁ。
だから、CPUレベルで0割による割込みが発生して、各プロセスに通知された
としても、それがC++の例外としてcatchできるわけではない。
(catchできる環境もあるだろうけど)
>>92は言語における例外を擬似例外とか言って相手にしたくなさそうだったけど、
そもそもこのスレは言語における例外をどう使うかを議論してきたわけで。

261 ：

>>229 はfinallyを何に使う気なんだろ・・・。

262 ：

finallyはガベージコレクタというか
スコープから抜けだしたときに自動的に
終了処理をできない言語では必須だろうけど、
ほとんどの言語ではできるから、使わないと思うんだが？

263 ：

例外と話ずれるけど、なんでJavaのfinallyってtryが必要なんだろ？
finallyブロックだけありゃいいだろうに。Windowの構造化例外ぱくったからか？

264 ：

>>263
お前はfinallyブロックでなにをするつもりなんだ？

265 ：

>>259
finallyとデストラクタが別の処理だったら？
そもそもそれなら何でfinallyがあるの？

266 ：

これ ； デリミタっていうんだけどさ、これをつけなきゃエラーになるような
そんな言語使ってる奴ってどうみてもゴミだと思うんだけど
もしかして「；」これ打ち忘れてコンパイルエラー出すのが楽しいの？
そうか、二度と話かけんなよ

今日何ゴミの日だっけ？

267 ：

天使◆uZeeeは新しいバリエーション作ったのか？ｗ

268 ：

というかfinallyの意味わかってないだろ。
tryブロックに入ったら、そこから出る時に必ず実行されるのがfinallyなんだから、
finallyだけだったら実行すべきタイミングわからんじゃない。

269 ：

>>265　Disposableな一時オブジェクトつくるのが面倒だからだろ。
Javaに限れば、ブロックスコープでの処理の強制実行がないから。

270 ：

>>258
>例外の全てについて書いてる訳じゃない
例えば？

271 ：

>>264
ファイルのcloseとか。
ファイル閉じるのに別にtryブロックは要らんよな。

272 ：

>>268
あれ？tryブロック入らなかったら、finally実行されないんだっけ？

273 ：

>>260
>CPUレベルで0割による割込みが発生して、各プロセスに通知された
>としても、それがC++の例外としてcatchできるわけではない。
出来ない環境ってなに？　具体的に。

274 ：

finallyを使わない人はリソース保護どうしているの？

275 ：

>>270
FORTRAN時代からException handlingと呼ばれた処理。
損壊データに対する例外処理とかな。

276 ：

>>274
デストラクタ、disposeとusing。

277 ：

>>274
あとOSとリソース管理ライブラリへの委託か。

278 ：

>>270
FORTRANの例外はCPUとまったく関係なく動くの？

279 ：

間違えた
270→>>275

280 ：

>>276,277
ファイルクローズやDBクローズもそれでやるのか？

281 ：

だからなんで「まったく」関係なく、が出てくるんだよｗ
交通事故にクルマの故障がまったく関係ないって言うバカがいるか？

282 ：

>>281
そういう意味じゃなく、CPUの割り込み関係なく例外が動くの？

283 ：

>>280
やるよ。やらない理由がないでしょ？

284 ：

>>282
そもそも、CPUの割り込みと関係ない例外を
話すのがこのスレのテーマだよ。

285 ：

>>273
0 割が C++ の例外として catch できることのほうが稀なわけだが。
できない環境を具体的に挙げろと言われれば、 VC++ で /EHs を
指定すればそうなる。

286 ：

>>285
それで？　どうやって実装しているの？

287 ：

>>286
上の方に書いてあるので読み直してください。
つか0除算なんて例外機構で処理するハメになっても何もそのプロセス単体じゃ出来んと思うけど。
本来0除算が発生しないようにプログラムを組むべきだし。

288 ：

>>278
だから例外機構と例外処理は違うと何度言ったら・・・。

289 ：

>>286 >>115 とか。

290 ：

漏れまくりだけど、整理してみた。
とりあえず、下に書いた関係に踏まえてレスしろ。
割り込み = new 割り込み();
入出力制御 = 割り込み;
タイマー等タイミング制御 = 割り込み;
例外機構 = 割り込み;
例外機構 = new OS例外();
例外機構 = new 言語例外();
例外機構 = new 戻り値例外();
例外処理 = new リソース開放();
例外処理 = new バックアップ復帰();
例外処理 = new 初期化による再試行();//Watchdog
例外処理 = new 上位プロセスに通知後終了();
例外処理 = new 例外に対するユーザー操作問い合わせ();
例外 = new 不正メモリ領域へのアクセス();
例外 = new データの破損();
例外 = new 不正データ入力();
例外 = new 入出力失敗();
例外 = new リソース不足();
例外 = new タイムオーバー();

291 ：

>>287
お前は例外処理でなにをしようと考えてるんだ？
0除算が発生したらやることはない？素人か？
実際に動くアプリを作ったことがないのか？

やるかやらないかは、アプリの仕様次第だが、
0除算が発生したときにやることはたくさんある。
・0除算が発生したことを画面に表示する。
・0除算が発生したことをログに記録する。
・スタックトレースを表示する。
・0除算が発生した処理のみを中断させ、正常なコマンド入力状態戻す。
やることはたくさんあるだろ。

292 ：

>>290
分かりやすく書きなおせ

293 ：

このスレにおける例外というのは、
CPUが発生させたとかハードウェアが発生させたとかは
気にするところではない。
プログラムのコードとして例外と呼ばれるオブジェクトを生成し
それを上位関数に返す行為のことを指す。オブジェクトの生成も
それを上位関数に返すのも、割り込みを必要としない。
一部の例外はハードウェアの状態が例外送信のきっかけに
なっているかもしれないが、そのことを意識してはいけない。
つまり抽象化。
ソフトウェアが割り込み機能を使わずに、
発生された物。それを例外としてこのスレで扱う。
割り込みの話はすれ違い。

294 ：

>>291
さてあなたの発見したゼロ除算はどこで発生したんでしょうね。
try
{
     Example object = new Example();
     object.Method(10,20,30);
}
catch(・・・)
{
     ・・・
}
こんな感じで入力だけに閉じてるなら問題ないし、>>291の対処法をとるのは正解だよ。
でも1つでも出力があったり、ゼロ除算を発生させる可能性のある式が露出してたら、
例外処理すら失敗する可能性がある。そもそも、ゼロ除算が発生する箇所が
最初から解ってるなら、ゼロ除算を発生させないように書けるはずだしね。

295 ：

>>294
> さてあなたの発見したゼロ除算はどこで発生したんでしょうね。
tryの中のどこか。
どこで発生したかは、例外オブジェクトが持っている。
例外オブジェクトに聞けば、発生した箇所を
スタックトレースとして取得できる。

常識だと思うんだが、こんなことも知らないの？

296 ：

>>291
大半の例外機構にリトライ機能がないのはなぜか知ってる？
例外が起こり得た範囲の値は全て信用できないからなんだってさ。
RuntimeErrorの類がチェック例外になっていないのはコレがひとつの理由だって。
もうひとつは、プログラマの意図を把握する手段が無いからだって。

297 ：

>294
例外をただの割り込みだと思ってるから
詳細な情報を取得できるってことがわからないんだろうね。
まあ、そういう勘違いしてしまう理由もわからなくはない。
お前が考えている例外はCPUが発生するもの。
つまり言語（プログラムのソースコード）とは関係ない。
例外が言語と関係ない。機械語上で起こることなのだから、
機械語がソースコード上のどこで発生したかを知るわけがない。
このように考えているのだろう。
だから、そういう意味の例外はスレ違いなんだよ。
このスレの例外は、ソースコードのメタ情報を持っている。
ユーザーがいくらでも情報を追加できる仕組みがある。

298 ：

>>296
> 大半の例外機構にリトライ機能がないのはなぜか知ってる？
ん？
例外機能とリトライ機能は全くの別物だからだよ。
お前が言ってるのは、「関数にリトライ機能がないのはなぜか？」のような
まったく意味不明なことを言っている。
リトライは例外機能とは別に追加するするもの。
どんな箇所にでもリトライ機能は組み込める。
そして組み込むかどうかはアプリの仕様できまる。

299 ：

>>295
0除算が影響するデータはtryブロックから絶対出てこないんだ。へぇ〜。
じゃあその結果はどこで受け取る予定だったんだろうね。
スタックトレースをそのプログラムで解析して、ゼロ除算になった変数を特定しデータを復帰するの？
俺が場所が解るってのはそういう事なんだけど。データ破損についていってるのにスタックトレースとか入門者かよ。

300 ：

> 例外が起こり得た範囲の値は全て信用できないからなんだってさ。
聞いたこと無いんだが。
信じる信じないも、そこに書いたコードで示されているとおり。
CPUの割り込みの話と勘違いしてるだろ？ｗ

301 ：

>>295
お前、0除算したときにどうするかは
一つに決まると思ってないか？
0除算したら、その値は0として扱うとか考えてるでしょ？

302 ：

>>298
文脈を読め。もしゼロ除算で他に影響が無いならリトライも可能になるはずだろうがって言ってんだろ。
ハゲを初め言語制作者はそれを無理だといってんの。

303 ：

>>300 今例外全般の話をしてないよ。
この1つのレスに答えてるだけ。例外自体は原因を特定できるけどそんな問題じゃない。
> 291 名前：仕様書無しさん [sage]： 2011/07/03(日) 21:11:02.26
> >>287
> お前は例外処理でなにをしようと考えてるんだ？
> 0除算が発生したらやることはない？素人か？
> 実際に動くアプリを作ったことがないのか？
>
>
> やるかやらないかは、アプリの仕様次第だが、
> 0除算が発生したときにやることはたくさんある。
>
> ・0除算が発生したことを画面に表示する。
> ・0除算が発生したことをログに記録する。
> ・スタックトレースを表示する。
> ・0除算が発生した処理のみを中断させ、正常なコマンド入力状態戻す。
>
> やることはたくさんあるだろ。

304 ：

あー、こんな話をきたことがあるわ。
アセンブラバリバリ出来る人が
Ｃ言語を理解出来ない。
C言語で変数使うと、
このメモリマップはどうなっているのか？と
聞くようなやつがいるって。
アセンブラの知識で気にすることを
C言語でも気にしてしまう。
本来気にする必要がないことを
気にしてしまう。そういう柔軟性のないヤツのことを。
ゼロ除算になった変数を特定することを
気にするのはなぜなんだろうねｗ
ゼロ除算になったソースコードの行を気にするのならまだ分かるが。（行は取得できる）

305 ：

>>297 にも同じ話な。割り込みの話じゃない。>>291のレスに閉じた話。

306 ：

この人は変数＝レジスタなんじゃないだろうか？ｗ

307 ：

めんどくせぇなぁ。
このコードでゼロ除算が発生した場合、
このクラスのオブジェクトが健全だと言えるのか？
もちろんこのコード自体に問題があるが、
具体的に回避策を上げてみろよ。
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
}
}
}

308 ：

見づらいんで直した。
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
                  }
         }
}

309 ：

この馬鹿相手にするのは疲れたから
0除算はこのスレの話題の対象外としていいんじゃないか？
0除算なんて、別にCPUの割り込みを使わなくて実装できるでしょ？
割り算がある箇所をコンパイルしたら、
if 割る数 = 0 then throw 例外 という機械語が生成される
擬似言語の話をしましょうやｗ

310 ：

でゼロ除算箇所を確実に特定し復帰する方法はある。
try
{
      y /= x;
}
catch(・・・ゼロ除算キャッチ・・・)
{
      >>303
}
ただし、この場合割り算一回に1個try catchが必要になる。
加えて、そこまで例外箇所を絞り込んでんなら初めからゼロ除算しないように修正しとくのが普通。

311 ：

>>307
バグがあるコードが健全かどうか聞かれても困る。
例外が起きたとき、オブジェクトの状態が異常になることがあるが
それを回復させるのがcatchやfinallyの役割。
catchやfinallyの中で不安定になっていても、
それを抜けるときに回復させていれば問題ない。

回復させるというのは、処理を続行するということはではない。
不安定（不定）である部分をなくすということ。
エラーとして親関数に返すことも回復の一つ。
これぐらいヒントを与えれば、自分で気づけるだろ？

312 ：

>>309 だから割り込みの話はしてないんだっつのアホ。
ゼロ除算があっても >>303の対処ができるとかいたんだろ。
それが無理だっつってんの。それが分かりゃ終わりだ終わり。
割込なんざどうでもいい。

313 ：

>>310
if(x==0) {
　　return 'error';
} else {
　　y /= x;
}
こうすることに利点を三つ上げろ。

314 ：

>>312
自分で、出来ることを>>310で
証明しているようにしか見えんのだがｗ

315 ：

>>311
具体的にコードを見せろ。素人じゃないんだろ。経験者なんだろ。さくっとコード出せるだろうが。
まさか、ゼロ除算に対するコード書いたこともないのに空論で語ってるだけのシステム土方か？
パッケージ開発した事があったりすれば解るだろ？

316 ：

>>312
結局さ、お前0除算を例外で処理することを
毛嫌いしているだけじゃね？
どうせ0除算するコードをなくすと言っても
計算する前に0かどうかチェックするだけだろ？
めんどくさいよね。特に式が長くなった時とかさ。
x = a + b / foo() - c;
とかさ。if使ったら面倒になるでしょ。
でお前はifしか使えないから、例外なんか食わず嫌いで使ってないだけ。

317 ：

>>315
まず、お前が先に
ゼロ除算に対する具体的なコードを見せろって
誰かに言われなかった？

318 ：

>>313
最初から、ゼロにならないことを保証したオブジェクトとれば済む話。
int Method(int x,NoZerroObject object)
{
return x /= object.getValue();
}
>>314
>そこまで例外箇所を絞り込んでんなら初めからゼロ除算しないように修正しとくのが普通。
おわかり？

319 ：

>>318
馬鹿だｗｗｗ
じゃあその変数に0を入れようとしたところで
例外が発生するだけじゃないかｗ

320 ：

>>317
問題があることを書いただろうが。
なんで問題があるっつってんのに自分で、問題が無いコードを提示すんだよ分裂症か俺は。

321 ：

>>320
お前が示すのは、例外を使わないで
0除算を防ぐコードだよ。

322 ：

>>318
ゼロにならないことを保証した変数を使えば
済む話だな。
>>310の例だと、
y /= NoZerroX ;

323 ：

>>319
ゼロ除算は発生しないよな？
そもそもNoZeroObjectで例外が発せいた場合は、
NoZeroObjectにゼロが入力されたことは明らかだ。
最入力なり何らりさせても他に影響が無い。
問題の発生箇所が初めから特定可能なのと、
>>308のように不特定なのでは全然問題が違うぐらい解るだろ。

324 ：

>>318があまりにも痛すぎるコードな県についてｗ

325 ：

>>321
例外を使うなとは言っていない。"ゼロ除算例外は対応できない"といってんの？はよコード出せや。
>>322
そうだよ。そのとおり。

326 ：

>>324 が素晴らしいコードを見せてくれと聞いて。

327 ：

>>325はちょっと間違えた。
>>294の場合以外は"ゼロ除算例外は対応できない"だ。

328 ：

誤解されてる気がするが、NoZeroObjectって名前のクラスを作るわけじゃないからな。
得られる値がゼロにならなければクラス名もメンバーも名前はなんでもいい訳だから。

329 ：

>>323
> ゼロ除算は発生しないよな？
つか、本末転倒だろ。
ゼロ除算エラーが発生しない代わりに
ゼロ代入エラーに変っただけじゃん。
割り算するたびに変数の値を、そのNoZeroObjectとやらに
一回代入して0かどうかの実行時チェックをするのか？
毎回毎回。ifでやる面倒さをなにも解決していない。
頭悪いよ。
もしゼロ代入エラーにならないのなら、
xが0になることもないわけで、
そもそもy/=xで例外が発生することもない。

330 ：

>>328
得られる値がゼロにならなければ、例外も発生しませんよ？
例外を使ったコードでも、
問題は解決ですよね。

331 ：

このスレ、Javaでしか考えられないヤツが異様に多い割に、
オブジェクトの完全性とかそういう概念にはかなり疎いのな・・・。

332 ：

で0除算にならないことをを保証する方法はないんだよね。
変数を使う前に、変数が0でないか
ifでチェックする方法はある。
だが、それは0除算にならないのではなく、
0除算になるコードに到達しないようにしているだけ。
もし到達してしまえば。0除算になる。

333 ：

>>331
ネットでググッても書いてないようなことはわからないよ（笑）

334 ：

0除算エラーがなぜ実行時エラーなのかというと
0除算ってのはコンパイル段階で除去できないからだよ。
たとえばユーザーの入力結果が0になることがある。
0にならなくても、長い計算の末0になることがある。
ユーザーが入力しなくても何らかの統計データを合計して0になることがある。
だから0にならないことを保証する方法はない。
あるとしたら、0にならないようにチェックするコードを書くことだけ。
だがそれは、書けば0にならないが、書かなければ0になるということ。
チェックコードを書くという保証はやっぱり得られないので、
0にならない保証もない。だから0除算を防ぐことを保証する方法はない。

335 ：

>>330　そうだよそのとおりだよ。
void Parse(String[] valueBlock)
{
try
{
tihs.polygon.push(new Point( valueBlock[0]., valueBlock[1] ) );
}
catch(・・・エラー・・・)
{
//体積が0になったので入力エラー
}
}
入力時点で0に対処してりゃどこに渡ろうが0になることはない。
まぁ、計算結果0になるのであればそこでの対処はいるが、
0除算エラー例外に比べれば範囲ははるかに特定しやすいし、
他へのの影響もない。
>>332　具体的なコードを書けって。

336 ：

>>334
>>303を読んだ上でいってるの？0除算を防げるかどうかがメインのテーマじゃない。
>>303のような対処法無理だし、最初からゼロ除算を防ぐ方法をこうじるしか無いっていう話なんだよ。

337 ：

>>336
少しお前は話をまとめろ。

１．何のために
２．どうやって防ぐか
たった二つだ。
その両方を答えよ。

338 ：

>>337
1. >>303のアホな対応により>>308のようなデータ破壊の連鎖を防ぐため
2. >>335のように意味論理的に0の発生を特定でき、他に影響が波及しないオブジェクトを使用する。

339 ：

>>338
すでに例外とは全く関係ない話をしているな。
計算結果が0になるとき、それはどうする？
0が代入できないオブジェクトに代入するわけか？
その時に例外が発生するだろ。
その時データ破壊が防ぐことが可能だとなぜ言い切れる？
お前のコードで言えばこう言うことだ。
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
　　　　　　}
　　　　}
}

340 ：

ずっとレス番間違えてたわ
>>303 は >>291 の事な。 引用してるから解るかもしれないけど。

341 ：

１．0除算の結果、その時の変数の値を信用することはできない。
２．ゆえに0除算を防げば、その時の変数の値を信用できる。

※１は間違い。

342 ：

そもそも勘違いは０除算をしたときに
オブジェクトが健全にならないと勘違いしていることだよ。
0除算に限らず、どんな例外が発生したとしても
そのクラスが正しく作られていない限り
オブジェクトは異常状態になりうる。
正しく作られていたなら、0除算が発生しても
オブジェクト自体は健全なまま。
それを踏まえて、0除算例外を0代入例外に
変えたとしても、オブジェクトは異常状態になりうるので
何の問題も解決しとらんのだよ。

343 ：

本質を考えないまま、0除算さえ防げれば
問題解決すると考えているから、
0除算を0代入エラーにすればと訳のワカランのことを言ってるのね。

344 ：

>>339
ならんよ。だってゼロ除算と違って発生場所が圧倒的に少ないんだもん。
try
{
      frameVector.sub(sourceVector);
      return new NoZeroVector( frameVector );
}
catch(・・・禁止されたゼロベクタ・・・)
{
       //図形が成立していないエラー
}
意味論理で考えれば、ゼロ除算の割る値になれる値が0になる箇所なんて
どう考えても最初から成立しない値になる。

345 ：

>>344
言葉が変だった。
>意味論理で考えれば、ゼロ除算の割る値になれる値が0になる箇所なんて
>どう考えても最初から成立しない値になる。
どう考えても最初から成立しない値が発生してるのですぐ解る。

346 ：

>>344
圧倒的に少ないから、ならないというのは
どう考えても論理的ではない。
それにお前初期値の話しかしてないよな？
0になるのは、なにも関数の引数にした時だけじゃない。
長い計算の結果の途中で0になることだってある。
それをどうやって防ぐんだ？
もしかしてすべての変数を0代入不可オブジェクトにするのか。
四則演算し全て使えなくなりそうだな。
なんか俺俺ライブラリ作ってRーしているのが目に浮かぶｗ

347 ：

>>342
>そもそも勘違いは０除算をしたときに
>オブジェクトが健全にならないと勘違いしていることだよ。
じゃ>>308を健全な形に書きなおしてくれ。
コードにすらおこせん御託はいらんから。

348 ：

>>345
最初から成立しない値が入っているのを防ぎたいののなら、
ifつかって変数の中身をチェックすればいいだけだよ。

349 ：

>>347
> じゃ>>308を健全な形に書きなおしてくれ。
それは不可能。ゼロ代入エラーにしても不可能なことを
解決することは不可能。
まずお前が、どんな状態でも完璧に健全になるというコードを書け。
短い例だけではなく、複雑な例でも対応できるやつをだ。

350 ：

>>346
意味論理的にって文字を読んだか？
体積1で高さが0の立方体とか存在すんのか？
机上の空論で語るなよ。具体的な例をあげてみろ。

351 ：

NoZeroなんたらを使ったところで、
try
{
　　NoZeroValue ret;
　　this.lock = 1;
　　ret = frameVector.sub(sourceVector);
　　this.lock = 0;
　　return ret;
}
catch(・・・禁止されたゼロベクタ・・・)
{
　　//図形が成立していないエラー
}
なんてコードを書かれたら、オブジェクトは不健全な状態になるわけだが。
この例だと、lockされたまま処理が終わってしまう。問題はなにも解決してない

352 ：

>>349
何行書かせる気だ、一行も書いてないくせに人にかけというな。
しかも、どんな場合でもというなら >>294 に書いた。

353 ：

>>351
入力地点に図形が不正で、座標がオカシイって伝えるに決まってんだろ。
その時点で、このオブジェクト自体は破棄されプログラム上に不正なオブジェクトは存在しなくなるわ。

354 ：

>>350
だから、お前は初期値の話しかしてないと言うんだよ。
体積を入力してください？
高さを入力してください？
if(高さが==0){エラー}
こういう単純な話しかしてないだろ？
こんなふうに関数の最初で0かどうかチェックできるような例なら簡単だろうさ。

355 ：

>>353
> 入力地点に図形が不正で、座標がオカシイって伝えるに決まってんだろ。
入力時点で、おかしいかどうか分からない場合だってあるだろ。
やっぱり初期値チェックだけで済む話しかしてないわお前。

356 ：

つでにゼロ除算エラーが入力地点まで上がっていった場合は、
どの入力した値が不正だったのか全く特定できなくなる。
図形の座標が原因とかそんな情報全くないからな。

357 ：

>>351でNoZeroなんたらを使っていても
オブジェクトが不健全になる例は示した。
話はこれで終わったはずだが。

それから、0除算をしたとしても
それまでの結果をローカル変数に入れておけば
オブジェクトは健全なままになる。

結局、例外が起きたとき健全かどうかは
例外の種類を変更しただけで解決する問題ではなく
その時のロジックで決まるんだよ。

358 ：

>>354
>>355
計算結果の場合は>>344に書いたよな。見たのかよ。

359 ：

>>356
じゃあこの例で、どの時点で不正だったか特定してみ。
try
{
　　frameVector.1sub(sourceVector);
　　frameVector2.sub(sourceVector);
　　frameVector3.sub(sourceVector);
　　frameVector4 = frameVector3 / frameVector1;
　　frameVector5 = frameVector3 / frameVector2;
　　frameVector6 = frameVector4 / frameVector5;
　　return frameVector6;
}
catch(・・・禁止されたゼロベクタ・・・)
{
//図形が成立していないエラー
}

360 ：

>>357
だからそのオブジェクトは破壊されるんだって。
なんで全体で捉えられないの？
try
{
    Example example = new Example();
    example.>>351の処理();
}
catch(略)
{
略
}

361 ：

>>360
お前、間抜けかｗ
>>351はお前が言うNoZeroなんたらを使った場合だぞ。
0除算例外を0代入例外にしたところで
壊れるって最初から言ってるだろｗ

362 ：

>>359
int i;
try
{
for(i=0;i<frameVector[i].length;++i) frameVector[i].sub(sourceVector);
{
catch(・・・禁止されたゼロベクタ・・・)
{
//図形が成立しんていない　i番目の座標が異常
}

363 ：

>>362
とんちかよｗ

全部一行につなげて書けば、
どこの行かはすぐに分かりますってかｗｗｗｗ

364 ：

>>362
コード書き換えんなよ。

365 ：

コード書き換えて、エラーの箇所を示すための変数を作って
いいなら0除算だって、どこの場所でエラーが起きたか分かるよな。
ここまで頭が悪い頑固爺は初めて見た。
int i;
try
{
for(i=0;i<value[i].length;++i) 100 / value[i]
{
catch(・・・禁止されたゼロベクタ・・・)
{
//i番目の値で0除算エラー
}

366 ：

>>361
そうですね。但し影響範囲は特定できる。
その情報はNoZeroが出した例外に入っているからね。
引数を書き忘れてたが、この引数自体は破損していないことが確定できる。
もちろんsource自体は、Exampleのオブジェクトに大しては毒だが、
新たなエラーの引き金にはならないことは解る。
例えばエラーメッセージとしてsourceの中身を参照する分には問題ない。
Example example = new Example();
example.>>351の処理(source);
>>363->>364
元がおかしいだろうが。なんで名前の一ベクトルが大量にあるんだよ。
その場合配列しか無いだろ。
仮に名前のついた配列が2本あったらその1個1個でtry-catch書くわ。

367 ：

> その情報はNoZeroが出した例外に入っているからね。
同じ情報が0除算例外にも入っている。
わかった？

368 ：

>>365 それがやりたいんならやればいいんじゃない？
意味合いが解ってて絶対ゼロが来ないと解っててもやってりゃいいんじゃない？

369 ：

話をまとめるとだな。
0除算例外か否かは全く関係なく、
エラー処理のロジックで例外時のオブジェクトの状態が決まるし、
また、エラー処理の作り込みのレベルで、どこまで詳細な情報を
取得できるかが決まるってことだよ。
いい加減気づけ。0除算かどうはは本質的に全く関係ないと。

370 ：

>>367 具体的にどうぞ。
例えば、exampleが図形で「図形で異常が起きたという例外」が発生すれば、
source側は無事だと解る。じゃゼロ除算の例外でsourceが無事であることをどうやって知るのかな？

371 ：

>>368
で、計算結果が0にならないということは
どうやって保証するんだ？

372 ：

>>370
お前こそ具体的に答えろよ。
exampleが図形で「図形で異常が起きたという例外」が発生すれば、
source側は無事だとなぜ言い切れる？

373 ：

>>369 まとめるのはいいが、元々は >>291 は無理って話だったんだけどね。

374 ：

そもそもsourceってどのコードの話だ？

375 ：

>>373
なにが無理なのか具体的に答えたら？

376 ：

>>372
「図形が異常で起きたという例外」の仕様がそういう例外だからだ。
IOExceptionがオーバーランが原因で発生することがあるか？
問題の範囲は特定できるんだぞ。
逆にゼロ除算。まぁ別にnullぽでもいいがそっちにそういう仕様はあるか？

377 ：

>>373
ん？
0除算が発生したときに、
「0除算が発生しました」とダイアログボックスを表示することは可能だし、
どうようにそれをファイルに保存すればログに記録できるし。
スタックトレースなら普通に出力されるし、
GUIアプリ、ウェブアプリで、0除算が発生しましたとでるが
アプリ自体は終了しないことはたくさんあると思うが？

378 ：

>>375 さんざん書いたよな。
>>294
>でも1つでも出力があったり、ゼロ除算を発生させる可能性のある式が露出してたら、
>例外処理すら失敗する可能性がある。そもそも、ゼロ除算が発生する箇所が
>最初から解ってるなら、ゼロ除算を発生させないように書けるはずだしね。
とか
>>308
とかさぁ。

379 ：

>>376
例外自体に、オブジェクトの状態を変更しませんと
定義することはできんぞ。
同じ例外を出したとしても、その例外を発生するまでのロジックで
オブジェクトの状態を壊すかどうかが決まるんだからな。
「このメソッドで例外が起きてもオブジェクトの状態を変えません」と書かれていれば、
0除算例外がでたとしても、ほかの例外と同じく、状態を変えないという仕様だ。

380 ：

>>377
スタックトレースをユーザーに見せるの？
あと、sourceの健全性は解らないだろそれじゃ。
sourceってのは>>366で出てくる引数のことな。

381 ：

>>378
それのどこが、
「0除算時にダイアログボックスを表示することが不可能（等）」という
理由になると言うんだ？

382 ：

>>388
> スタックトレースをユーザーに見せるの？
お前は実務経験無いのか？
スタックトレースをユーザーに見せるかどうかは、
アプリの仕様しだいだろ。
ちなみに実際に見せてるアプリは多いぞ。
-vオプションとか-dオプション付けたら表示するものもある。

383 ：

>>380
366の引数？
それ、例外が発生したら壊れるよ。
壊れるようなコードを書いているからね。
で？

384 ：

繰り返すが、例外の種類で
オブジェクトを壊すかどうかなんて決まったりはしない。
例外発生時にオブジェクトを壊すかどうかは、ロジックで決まる。
同じ例外を出したとしても、その例外を発生するまでのロジックで
オブジェクトの状態を壊すかどうかが決まるんだからな。
「このメソッドで例外が起きてもオブジェクトの状態を変えません」と書かれていれば、
0除算例外がでたとしても、ほかの例外と同じく、状態を変えないという仕様だ。

385 ：

やっぱり0除算をCPU例外の0除算と
勘違いしている馬鹿ではないだろうか？

ぜんぜん違う。0除算はほかの例外と全く一緒。
0で割ったときに発生するというだけで
得られる情報も、オブジェクトの状態も
全く変わらない。

386 ：

え？ 0除算が発生したら
その時点でオブジェクトが壊れるんじゃないの？
たとえば、全く関係ないプライベート変数の値が変化したり。
って本気で思ってそうｗ

387 ：

>>381
んな事いってないだろ。「0除算が発生しました」という無能の極みみたいなメッセージ出すだけならもんだいねぇよ。
それより、健全なオブジェクトと壊れたオブジェクトを判別できない事。なんかい同じ事を書かせんだよ。
問題が発生したオブジェクトが特定できないと、どれが壊れてるか解らないまま処理を継続する事になり、
多少処理する例外処理も失敗するわ、健全なデータも判別できないから、健全なデータも破棄する事になるわ問題が発生するから処理継続は無理と書いてる。

388 ：

>>382
デバッグ機能はともかく、エラーメッセージ替わりにユーザーに見せるのは最悪だけどな。

389 ：

>>384
そうかもね。じゃ変更する場合はどうなるんだい？
>>385
　ゼロ除算やら割り込みが問題じゃないんだよ。
10箇所で発生する例外をまとめて捕まえて、
10箇所のうちどれが壊れてんのか、それがどこに影響してんのか
特定できない状態で例外処理やってるってのがおかしいって話。
>>386
　>>308

390 ：

じゃ極論しよう。
・壊れたオブジェクト
・無事なオブジェクト
この2種類を判断できない状況で処理を行うな。以上。

391 ：

>>389
ん？ >>308がどうかしたのか？
ロジックによってオブジェクトが壊れるかどうかが決まる
0除算例外にだけ特別なことは何も無い。
そうだよな？

392 ：

>>391
そうだよ。
・壊れたオブジェクト
・無事なオブジェクト
この2種類を判断できない状況で処理を行うな。って話だよ。

393 ：

>>387
例外発生時に発生する副作用が特定できるように、
例外安全性を意識した設計と文書化を行いましょう。
それができてない前提であれば、あなたの言うとおりかもしれません。
でもそれは例外という機能による不可避な問題ではないのです。

394 ：

>>391
あ〜ロジックによってってのはちょっと誤解があるな。
ロジックによって壊れないことが保証されている場合は、そのとおり。
ロジックによって壊れるかもしれない場合は、例外で判断するしか無い。

395 ：

もう一点、この問題はエラー通知方法に例外を使った場合にのみ発生するものでもありません。

396 ：

>>390
当たり前ｗ
それをお前は例外の種類で区別できると
言っていた大馬鹿者ってだけだ。
ロジックの途中で例外が発生した時、オブジェクトが壊れるかどうかは
ロジックの内容できまるのであって、例外で決まることはない。
たとえ0除算が起こったとしても、それまでの処理の結果を
ローカル変数を使うなどしてオブジェクトを変化させていなければ
オブジェクトが壊れることはない。
また、他のどの例外が発生したとしても、その例外が発生するまでの間で
オブジェクトの状態を変化させていれば、オブジェクトは壊れる。
たとえば、NoZeroObjectに0を代入する前に、オブジェクトの状態を変化させていれば
当然0を代入して例外が発生すると、オブジェクトの状態は壊れている。

397 ：

> ロジックによって壊れるかもしれない場合は、例外で判断するしか無い。
無理。こういうコードがあったとき、例外の内容を見て
壊れているかどうか判断することは不可能。

void func() {
　try {
　　this.lock = true;
　　任意の例外
　　this.lock = false
　} catch (任意の例外) {
　}
}

398 ：

やっと話が集約してきたな。
0除算とは関係ない話だと
最初に行ったとおりさ。

399 ：

まとめるとこうか。
1.
・壊れたオブジェクト
・無事なオブジェクト
この2種類を判断できない状況で処理を行うな。
2.
　・ロジックによって壊れないことが保証されている場合は、そのとおり。
　・ロジックによって壊れるかもしれない場合は、無事かどうかを例外で判断するしか無い。
健全なオブジェクトを判断するには、例外の判別が必要。

400 ：

>>398 そうだな。もともと >>291がおかしいって話でボヤけてたが本体がみえてきたな。

401 ：

> 　・ロジックによって壊れるかもしれない場合は、無事かどうかを例外で判断するしか無い。
あ、これは訂正すべきだな。
ロジックによって壊れる場合、例外を見たところで
無事かどうか判断できない。
そもそも「ロジックによって壊れる場合」は壊れるに決まってるかｗ

402 ：

>>400
おかしいという根拠は
最後まで出てないと思うがｗ
実際に、0除算例外が起きたときに
ダイアログにそのことを表示するコードはかけるし。
その証拠としてはこのコード。
class Sample implments Interface
{
　　public void setValue(int value){・・・}
　　public int getValue(){・・・}
　　public void exampleMethod()
　　{
　　　　try
　　　　{
　　　　　　Example example = new Example();
　　　　　　example.Method(this);
　　　　}
　　　　catch(・・・ゼロ除算キャッチ・・・)
　　　　{
　　　　　　ダイアログ表示("0除算が発生しました");
　　　　}
　　}
}

403 ：

0除算に限らず、任意の例外(0除算含む)が発生したときに
そのことをログに記録するなんてことは
普通に行われているよ。

404 ：

>>397
例外はランダムじゃないから判断できるだろ。
void func(Source source)
{
try
{
int value = 0;
・・・処理・・・
source.add(value);//add内で例外が発生した場合、sourceは破損。
}
catch(・・・funcが所属するオブジェクトで発生した例外・・・)
{
//・・・funcが所属するオブジェクトが壊れた例外を出す。
}
}
受け取る側は、funcが所属するオブジェクトが壊れた例外かそうでないかで、
sourceがまだ健全であることを判断できる。もちろんaddが行われてないんで
その分結果が違うが。source自体に変化が無いことは解れば十分。

405 ：

結局、>>291に難癖つけたやつが
的はずれなこと繰り返してただけじゃねーかｗ

406 ：

>>402
それを全ての割り算に書くならねぇ・・。っていう話でNoZeroとか出てきたんだけど今更もどるのか、あの話に。

407 ：

>>404
だから判断できるのは例外ではなく
そのロジック限定のことだろ。
ロジックを見ることなく、例外だけで判断できるというのなら
そのロジック隠した。このロジックで例外が発生したとき
壊れないと言い切れる根拠は何だ？
void func(Source source)
{
　　try
　　{
　　　　・・・処理の内容は秘密・・・
　　　　例外発生
　　　　・・・処理の内容は秘密・・・
　　}
　　catch(・・・funcが所属するオブジェクトで発生した例外・・・)
　　{
　　　　//・・・funcが所属するオブジェクトが壊れた例外を出す。
　　}
}

408 ：

>>405
そうだね。全ての割り算に>>291を書くなら的外れだろうね。以下略。

409 ：

>>407
　・ロジックによって壊れないことが保証されている場合は、そのとおり。
　・ロジックによって壊れるかもしれない場合は、無事かどうかを例外で判断するしか無い。

410 ：

>>406
> それを全ての割り算に書くならねぇ・・。
何のために？

411 ：

>>409
だから、例外を見ただけでオブジェクトが壊れているかどうかを判断することは
不可能だってばｗ
どういう理屈で判断できるのか
説明してみ。
どうせこのロジック（メソッド）では壊れないと
書いてあるからが答えだろ。
ほら例外の種類ではない。

412 ：

一体なんのためにすべての割り算に例外を書くのか理解出来ない。
例外処理は一箇所にまとめることが可能なのを知らないのだろうか？
そのまとめた例外処理コードから、例外が起きた詳細な情報を
取得できることを知らないのだろうか？
例外をキャッチするだけの人だと、自分で詳しい例外を作って投げるという発想がないのかな？

413 ：

>>410
>>412
ほい>>399
>>411
ほい>>404
「funcが所属するオブジェクトが壊れた例外」がfuncが所属する
オブジェクトが壊れた時にしか出ないことを仕様として決めてる限り明らかじゃん。

414 ：

>>413
さっきから論破されたリンクばっかり出すなよｗ

415 ：

> 「funcが所属するオブジェクトが壊れた例外」がfuncが所属する
> オブジェクトが壊れた時にしか出ないことを仕様として決めてる限り明らかじゃん。
うん、だからロジックによって決まると言うことでしょうがｗ
もしその例外を俺が作ったロジックから投げたとして
例外を見れば、オブジェクトが壊れないと判断できるか？
実際に可能なことだぞ。俺が作ったロジックから
その例外を投げることは。

416 ：

> 例外をキャッチするだけの人だと、自分で詳しい例外を作って投げるという発想がないのかな？
まさにこれかｗ
例外をキャッチするだけだから
自分で投げることを想定していない。

417 ：

>>416
>>404で投げてんじゃん。

418 ：

論破した、と必死に主張する奴に限って...

419 ：

>>411
そういや、そうだよ。メソッドの仕様に書いてあるからだよ。うんそのとおり。
・ロジックによって壊れるかもしれない場合は、無事かどうかを例外で判断するしか無い
がよく解らないメソッドから出てきても例外だけで判断できると解釈されたんなら誤解だ。
どのオブジェクトが壊れたとき、どの例外が発生するかはメソッドの仕様で決まってる。
だから、どのオブジェクトが壊れたか判断できると書いたほうがただしかったか。

420 ：

　俺は、筋の通った間違いの指摘は、認めてるつもりだが、ここぞと同じ事を
言って掛かってくるやつ多いな。単に論破したいだけのヤツが多いんだろうか。

421 ：

俺様が認めてやってる感ぶりぶりで素敵！

422 ：

>>419
また自分の言葉を訂正したな。
結局お前が言っていることは何一つ
正しくなかったってことじゃねーかｗ

423 ：

>>291は正しかったってことか。
結局否定できなかったもんな。

424 ：

>>422 訂正ねぇ。したよ。言い回しが違うだけでいってることは他の人と同じよだったから。
内容は>>404に書いたものと変わってないけど。
>>423
>>291を全ての割り算に書からないなら
・壊れたオブジェクト
・無事なオブジェクト
この2種類を判断できない状況で処理を行うな。
が守れないよねって話を刻々と続けてきたと思うけど。

425 ：

>>424
誤解をまた生みそうなんで訂正。
>>423
・壊れたオブジェクト
・無事なオブジェクト
この2種類を判断できない状況で処理を行うな。
を守るには、>>291の方法だとtry-catchを全ての割り算に書かなきゃならないよね。

426 ：

>>424
だからすべての割り算に書く必要はないんだってばｗ
例外処理はひとつにまとめられるの。
そして一つにまとめたところで、
ローカル変数に途中の処理結果を入れていれば
どこで例外が起きても、オブジェクトのの完全性は保たれるんだってば。

427 ：

> を守るには、>>291の方法だとtry-catchを全ての割り算に書かなきゃならないよね。
なんで？

428 ：

>>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の健全性が高くなるのはたしかだね。

429 ：

いつまで続けてんだよ
>>92はだいぶ以前からスレに沸く見当違いさんだから触るな
初レスとか嘘ついたり、もう来ない宣言のあと当たり前に自演したりとか、相手するだけ無駄だぞ

430 ：

>>428
はぁ・・・。確かというか、例外が発生する可能性があるコードの前、
つまり関数の最初に引数をチェックして、それでOKならそれでいい。
だが引数チェックしたところで、すべての例外が起きなくなるわけじゃない。
むしろゼロ除算例外のように、引数チェックで例外が発生しないことを保証できることなんてまれ。
（つーか、ゼロ除算例外だって計算結果が0になってその値で割れば発生するから引数をチェックしたところで完璧ではない）
だから例外を発生させないようにするという考えは現実的ではなく、コード上のどの箇所で例外が起きても、
問題ない作りにする。これは0除算の限った話ではない。すべての箇所で同じような作りにする。
で、コード上のどこで例外が発生したとしても、問題ない作りにするには、
オブジェクトの状態を変えるコードは処理のなるべく後のほうでやって
途中はローカル変数のみを使ってコードを書く。
これはある程度実戦経験積んだ人にとっては当たり前に書くコードなんだが・・・。
ため息しか出ないよ。こんな初歩中の初歩をしらんやつだったとはな。

431 ：

>>429
ゼロ除算やら割り込みが問題じゃなくなってるんだけどOkey?

432 ：

ついさっきまで、ゼロ除算だと・・・って
なんかゼロ除算だけに存在する問題が何かがあると
考えていた間抜けがいたけどなｗ

433 ：

>>430 こっちの要点は健全なオブジェクトと壊れたオブジェクトを判別し、
安全な状態で処理または、例外処理を継続すること。
まぁ、そもそも保全に対する方向性が違うんだろうね。
俺だって"割り算毎に例外チェック"すんのは馬鹿げてると思う。
でも>>291の方法だとそうは行かない。だから、それを避ける手段を
NoZeroの流れと、メソッドの仕様と例外の区別を利用する流れで提示した。
まぁ、方向性が違うから他の人には納得する点は一切なかったらしい。
10個20個例外が発生する箇所をまとめてキャッチしたらどれが壊れてるのか解からん。
根本的にはゼロ除算は関係ないし、Nullポだろうが、
SQLExceptionだろうが、IOExceptionだろうが同じ話だったんだけどな。
それじゃ消えるよ。めんどうだから。

434 ：

>>433
> でも>>291の方法だとそうは行かない。だから、それを避ける手段を
> NoZeroの流れと、メソッドの仕様と例外の区別を利用する流れで提示した。
それじゃ無理。あくまで関数の最初でチェックできることにしか対応できない。
途中の計算で値が0になったらどうする？
どっちみち処理の途中で例外が発生することになる。
処理の途中で例外が発生することを防ぐことは不可能なのだから、
その場合でもオブジェクトが壊れないようにするには処理の途中でオブジェクトの状態を
変更しないようにローカル変数を使う。普通はそのようにコードを書く。
どうしてもそれが不可能な場合のみ、catchかfinallyで復帰処理を書く。
それがコーディングのセオリーだ。
> 10個20個例外が発生する箇所をまとめてキャッチしたらどれが壊れてるのか解からん。
わかる。例外オブジェクトにどこが壊れているか情報が格納されている。
どうしてもわからないのなら、自分で情報を追加すればいいだけの話。
結局お前は、技術力不足により意味のない俺俺解決方法を思いつき
それを偉そうに語っていただけ。お前の保全に対する方向性が斜め上を向いていただけの話。
実戦経験がないから、変な方法を思いつく。頭が良いのではなく頭が悪い証拠だ。
> それじゃ消えるよ。めんどうだから。
できれば今後一切出てくるな。初心者の相手は面倒だ。

435 ：

>>434
>>219さんお疲れ様。あんたもお帰り。

436 ：

>>435
さっさと消えろよ。自分で言ったんだろ。

437 ：

>>436
お前の敵はひとりかよw
>>434 も>>433もどっちも実践あるとは思えんから言っただけだ。
両方帰れ。

438 ：

>>437
お前が一番実践なさそうだな。
何一つまともなことを言ってなさそうだからな。
お前の発言はどれかね？ｗ

439 ：

>>438
おれこの口論にゃ参加してないよ。
話を聞き出すならともかく、自分の意見を相手に
押し付けあうなんてバカバカしいじゃん。
社会人なら解るはずだけど？
だから、どっちも実践あるとは思えないって書いたの。

440 ：

> おれこの口論にゃ参加してないよ。
うんだろうね。
なにも発言せず、偉そうな態度。
よくあるパターンだｗ

441 ：

最初から例外でないようにかけばいいじゃんバカだな
本当にバカだな
書く必要ないさっさと消えろ

442 ：

え？

443 ：

真性の阿呆はそっとしておいてあげてください

444 ：

>>441
こういうアホが理解できないんだよな

445 ：

久々にスレ覗いたけど前に比べて活気がないね

446 ：

適度な阿呆が独自論展開しはじめると盛り上がるけどねえ
ここまで酷い阿呆だとオモチャにもならないんで

447 ：

餓鬼にはオモチャを与えないとな。

448 ：

例外理解してない人は、例外意外もわりと理解してないな

449 ：

いい加減な集約例外とか、統一性のないログ処理とか
もうやだ！

450 ：

例外とかあんま関係ないけど、
条件が間違ってたとか、明らかにコーディングミスで
落ちてる場合って客にどういうメッセージ見せるべきよ？
「予期せぬエラーが発生しました」「システムエラーです」っつうのも、
明らかにうちのミスであって、システム的に未知の異常が発生した
訳じゃないから言い訳がましいように感じる。

451 ：

パスワードが違います

452 ：

もういちどやりなおしてください。つづくばあいはれんらくしてください。的な。

453 ：

もう一度やり直しては不味くね？
バグで有る以上、
バグかどうかは判断できてもどこで発生したかはわからんだろ。
事態を深刻にする可能性があるぞ。

454 ：

仕様上予期してないわけだし、システムがエラーなんだからそのままでいいだろ
だいたい、コーディングが悪いのかほんとに未知のエラーなのか判断できるなら対策しろよ

455 ：

>>454
テスト漏れな異常引数とか配列のコレクションのオーバーランとか
すぐバグだと解るけど、対策なんてできるか?

456 ：

ひとついわせてもらうと
こんなスレが伸びちゃうのが　日本のレベルの低い由縁

ありえねーだろ・・・・・・・　　なんで理解しない

457 ：

kardとか書いちゃうヤツが、ずいぶんよその国に詳しいんだな。

458 ：

触るときは本当に反応してあげる価値がある相手かを考えてから触ろう
技術不足でも、想定できてなかったら想定外のシステムエラー
もみ消したりして続行されるほうが追々困るので、その原因がバグであってもなんであっても
想定してない以上、中断して通知する必要あるよ

459 ：

それは解るんだが問題はどう通知するかなんだよ。
予期せぬエラーと報告する場合で、エラーの発生頻度が低いと
ユーザーが無視可能性があるでしょ。バグだったら取り返しが
つかないことになる前にさっさと報告してもらったほうがいい。
なので、やんわりと「バグだよごめんぬ。さっさとバグレポート送ってね。」的な事を
ユーザーに伝えたいんだ。それをどう伝えるべきかいい方法が思いうかばん。

460 ：

>>459
このバグを報告したら1万円あげますって書けばいい。

461 ：

>>459
例えば給与会計のシステムで
　誰かの勤務時間登録でエラーが出たらガン無視してExcelで手打ちする
みたいなオモシロイことをしやがる会社はある。
ユーザーもアホではないんで、なんとか凌ぐもんだよ。
あまり神経質になりすぎてもこっちが辛いだけでな。
まぁ今のところは本当の意味での例外、例を挙げれば
　ソフトウェア以外の部分で生じたトラブル(LANケーブル断線とか、ODBCとかJDBCの設定ミス)
は例外扱いくらいだ。
DBのコネクション張れないとか、あるはずのJPGファイル読めない(ユーザーがファイルいじってね？)とか、そんなの。

462 ：

Excelで手打ちして
は
Excelで手打ちして上司に『ごめんこの人たちデータ入りませんでしたてへっ☆で済ます
の意味だが。不思議に給与を振り込んでくれる素敵な上司に乾杯。

463 ：

>>461
お前みたいなゴミがいるから腐敗していくんだろうな
身の程を知れクソゴミ

464 ：

このニートさんどんだけ暇なの

465 ：

>>463
どーでもいいから資料出せよ。別スレで出せって言ったろ？
ここで書いてもらっても構わん。

466 ：

ソースだせ→スルーして他スレ荒らしは典型パターン
逃げるか火病るかで話にならないので誰もソース出せとは言わなくなったぐらい

467 ：

一々触るやつも同類まとめてスルーしとけｗ
>>459
一度納品して、検査がおわっても見つかってない不具合であれば、あとは保守の内容次第だと思う
管理者の日常業務にログチェックを入れてあればそのうち見つかる
定期的にログチェックをやってるなら、エラーが出てたらその時点で対応検討できるからな
一度作ったら放置のような客のとこでは、そういうのは無理だし、そこは割り切れ
まぁ、大きな問題になると困るようなシステムならある程度の管理者がつくから、
ちゃんとログの内容チェックしてくれると思うよ
全体仕様に関われる案件であることが前提だけど、
エラー時のログファイルを日時でファイル名分けた別ファイル出力するようにしておくとかやると
普段あまりログの確認をしないところでも、エラーが見つけやすくなるから、そういう手もある
あとはログチェックから不具合調査依頼を出すための資料収集の手順書を作ってあげたりすると
必要な情報が取りやすくなるので、不具合起きるとマズそうな案件とかでは重宝するかも？
別ファイル化は前後の記録が取れないから、面倒なこともあるので一長一短だけどな

468 ：

あとはメール通知とかって手もある。大きなシステムとかだとログも膨大だから
エラーや警告が出てたら通知メールを飛ばすって仕組みを用意してやる
もちろん、メールがこけることもあるので、定期的な死活監視用の通知も必要になる
大きなお仕事とかだと、そんなのもあると思う
いまやってる仕事は、業務エラーもシステムエラーも一緒くたに
Exceptionでキャッチしロギングする過去の遺産の糞F/Wの上に乗っかってるから
ユーザーが入力ミスしただけでスタックトレース吐かれて、ログチェックどころじゃねぇけどな！
例外を正しく使えないプログラマが多いね

469 ：

>>455
そんなイラつくなよｗ
ちょっとキチガイなやつだ
そっとしておいてやれ

470 ：

いらん安価いれてしもた

471 ：

>>469
例外を正しく使え！

472 ：

ふぅ。やっぱりこの結論に達するよねｗ

http://d.hatena.ne.jp/ryoasai/20110221/1298297258
システム系の例外は実行時例外＋AOPでハンドリングするのがベスト
インフラ層のチェック例外はやはりJavaのBad Partだと思う

473 ：

運用環境で発生する可能性が常にあり、なんかしらの処理を行う必要があるものなら
どのみち補足するし、別に検査例外で構わんとは思うけどな
ただ、フレームワークの多くのメソッドに throws Exception とかやられるくらいなら、
全部実行時例外にしてくれよって毎度思う

474 ：

Android触っててJavaの割には妙にストレスが少ないと思ったら
ライブラリがほとんど検査例外使ってないんだな

475 ：

>>474
Androidは組み込みだからいつでも落ちますって前提。
中身ほとんどCで、システムのベースはC++だし。

476 ：

JNIでC++アクセスできるなら、最初からC++ベースだけでもアプリ組めるようにしてほしいわ。
軽快に動くメディアプレーヤーつくろうとするとJavaとの通信が邪魔すぎる。

477 ：

趣味マなんだけど例外って重要だと言われる割に
書籍とか探しても触りしか触れられてる物がおおくて正しく使えてるのか不安にはなる
まあ、趣味レベル何でとにかく動けば良いんだけどね、なんか気持ち悪い感じになる

478 ：

例外だけで一冊にまとまってる本あるだろ。

479 ：

7スレ目でまだテンプレすらないぞ
先に言っておくが俺は作らないぞ

480 ：

>>478
あるの、マジで教えて。

481 ：

>>478
ワロタｗ
そんなに複雑な仕組みなんてすてちゃえばいいのになｗ

482 ：

えっ

483 ：

だってそんなに複雑ってことはたくさんのバグや不具合を内包してるってことだろ？

484 ：

そうだな。CPU捨てちまえ。

485 ：

try-catchについて本一冊書いてんじゃなくて、
errnoを含め、例外情報を受け取った際どうしょりするか、
どういう状況は例外状況と判断するか、例外情報とは
どのような情報をまとめるべきかを書いてんだろ、
Exceptional〜とかな。
例外を try catch throw 構文そのものだと思うな。

486 ：

>>485
だからそんな複雑なもんはいらねっつーのｗ
１０得ナイフを１０００得ナイフにして「ほら、使えるでしょ？ね？ね？」っていってるアフォといっしょだな

487 ：

java で throws Exception をみかけるとやる気なくなる
フレームワークの共通処理とか以外で catch(Exception e) を書かざるを得ない状況になるとげんなりする
こういう奴がいる環境だと、ほんと検査例外は邪魔にしかならんな

488 ：

何も考えずログ吐いて握り潰しはもっと多い

489 ：

ログだけでいいじゃん
何すんのさ

490 ：

ユーザー通知したり代替処理したりは普通にやるし、考慮されてなければ確認する
仕様書にないから無視とかやってると、使えないマだなっていうレッテルが貼られるわなぁ

491 ：

仕様書にない例外はバグだろ

492 ：

>>486
日本語ワカリマスカ〜？

493 ：

>>491
例外が仕様書にかいてんのもおかしい話だけどな
仕様書に書いてんのは、ErrorとWarningか復帰方法だろ

494 ：

例外は相変わらずよく釣れるなｗ
>>491←こーゆーなんもわからない奴ってなんで減らないの？

495 ：

>>494
たった１行で相手が「なんもわからない奴」って断言できる人間がいるからじゃないかな。
お前にとっては、いつまでも「なんもわからんない奴」だらけだろうよ。１行で判断するんだから

496 ：

ケンカ腰になるな

497 ：

匿名掲示板なんだから1レスしか書き込まれなかったら
そこで判断するしか無いだろうに
匿名の場において個人は、ひと続きのレスという
一時的な存在にしか見えないんだから

498 ：

例外が理解できてない馬鹿は仕様と戦う馬鹿でもある

499 ：

エラーはすべて例外にする例外原理主義
慣れると正常系と異常系の処理がきっちり分けられて便利

500 ：

例外は東京電力の非常用発電機みたいなもの
想定外です

501 ：

>>497
悪いこた言わないから、心療内科池

502 ：

IDやIPの類も無しに違う文体、違う内容を書きこまれて
同一人物だと断定できるんだ(´・∀・｀)ﾍｰすごいね

503 ：

相変わらずこのスレは痛い子が多いな

504 ：

>>502
おまえは一体何を言ってるんだ？
誰が「同一人物だと断定できる」とか、できないとか言ってるんだよ。
脳みそおかしいだろ

505 ：

キチガイに構うなよ

506 ：

まぁ、「心療内科池行け」としか言ってないわな
それが何を意味するか解釈すんのは人それぞれだけど

507 ：

昔からこのスレは頭の弱い子沸いてるんだから、いちいち構うなって

508 ：

例外なんて書かねーよ感じろバーカ

509 ：

他の要求と矛盾しない限り書いておけよばかw

510 ：

例外すら使い分けとかできない奴ってまだ居るの

511 ：

あげ

512 ：

お前らって時給1000しかもらえNASAそう。

513 ：

どうした、何か辛いことでもあったのか？

514 ：

その前にお前ら自身が例外な事に気づけ

515 ：

それをキャッチできずにスルーしてるからどうにもならんのじゃないか（´・ω・`）

516 ：

使えないっていうか、理解してないし理解しようともしないし理解する能力もないっていう、そういうのが多い

517 ：

問題押し付けるの止めてくださいというのも多い。

518 ：

いやそれは自分に出来ないことを他人に押し付けるのは誰もいい顔しないだろう

519 ：

押し付けるとか、そういう使い方をするもんじゃないしなｗ
処理からするとどう対応するかが決まってない問題とかは例外
処理を呼ぶ側がどう処理するかを決めれるようにするものだしな
同じ対応する異常系を集約しやすいからちゃんと作ってあれば超便利
でも例外理解できない奴は例外==悪い事、程度の認識しかなくて、発生するとふぁびょる

520 ：

そんなに複雑な理由じゃなく、単に正しい結果を返せないなら例外だろ。

521 ：

職場で例外処理使用禁止になりそうです。
あるできるプログラマーが例外を理解してなくて、
例外の使い方を間違えて、例外が遅くてわかりにくい機能だということにされた。
Googleのコーディングルールに例外を使わないよううたわれていることが致命傷だった。

522 ：

>あるできるプログラマーが例外を理解してなくて
できねぇだろそいつ。つかAPIが投げてくる例外どーすんのさ。全部呼び元で握りつぶすのか？

523 ：

そんなんが「できるプログラマー」って時点で終わってるので、
とっとと逃げて、トドメのために魚雷ぶちこんでやるのが男の情け、という気がする。

524 ：

運用時に例外投げてくれる可能性があるからＡＰＩのはなんとか握り潰して
自分等では使わない方針は俺は賛成
そもそもメソッドの結果なんて成功か失敗か（bool型）で足りるのに
わざわざ返す例外を１つ１つ全部呼び元で対処しなくちゃいけない仕様はおかしい
１００箇所でメソッド呼んだら１００箇所で同じ対処せなあかんのかと・・・？
使う側がマニュアルみて例外の対処１つ１つ・・・ってその発行した例外が出たときに
何をしなきゃいけないのか知ってるのは間違いなく例外なげた奴のほうだろ？
だったらてめぇのメソッド内でやれよ
外側からできる仕様にしてやっからよ

525 ：

その場で復旧できてそこまで共通化する必要があるなら
ラッパーなりヘルパーなり作ればいいだけだろ
なにプログラム初心者でもわかってくれるレベルの事に長文書いてんのｗ

526 ：

書き忘れましたが言語はC++なのでAPIが例外を投げてくることはありません。
そのできるプログラマーはちゃんと実力のある人です。ちなみに外人です。
Googleのコーディングルールでも例外禁止だし、
Effective C++の著者Scott Mayerも例外に否定的だし、著名なアメリカ人にも否定派は多いようなので、
例外はちょっとまだ受け入れられていない感じがします。
パフォーマンスの問題とか、挙動を予測できない問題とかは、言いがかりに近い誤解なんですけどねー。
いくら説明しても無駄なので、実績のある著名人の論文でもいくつか出さないと通らないっぽいです。

527 ：

例外発生時にいちいちキャッチする必要はないでしょう。
例えばシミュレーションプログラムを実行中に0除算が起きた時、適当な値に直して継続させることはマレで、
その計算の一部分または全体をキャンセルしてしまうのが普通では。
つまりcatchはthrowに比べて大幅に少ないはず。
そこのパラダイムシフトに気づかないと例外の利点は理解できないと思う。

528 ：

キャンセルするのに例外使うんだろ
で、失敗した時の通知やログ出力にcatchを使う
return のチェーンを置き換えただけ

529 ：

>>524
エラーありか、無しかだけが欲しいなら
catch(...){}で捕まえても構わんのだぞ

530 ：

まぁたしかにC++ならあんまり例外使いたくない気も。解放し忘れとかやっちゃいそうだし。例外使わなくてもやっちゃうんだけどさｗ

531 ：

クラスきちんと設計できてるなら例外使わないとむしろめんどいケースが多いな
何が楽しくてチェックして結果リターンして、みたいなアホなこと繰り替えさにゃならんのか、ってなるな
それを回避しようと思ったら、例外を使わない前提で
階層構造にはなるべくならないようなアホ設計をやらにゃならんくなる
そして1メソッドの行数がえらいことになるなどが多数出てくる

532 ：

ああそうかそういうことか
1メソッドにずらーーーーーと書くようなコーディングルール()な環境だと
例外いらないって考えが生まれるのは理解できなくもないな

533 ：

> 書き忘れましたが言語はC++なのでAPIが例外を投げてくることはありません。
間違いです。お前素人ですか？
> 書き忘れましたが言語はC++なのでAPIが例外を投げてくることはありません。
間違いです。お前素人ですか？

> 書き忘れましたが言語はC++なのでAPIが例外を投げてくることはありません。
間違いです。お前素人ですか？

534 ：

> 書き忘れましたが言語はC++なのでAPIが例外を投げてくることはありません。
だっせｗｗｗｗ
> 書き忘れましたが言語はC++なのでAPIが例外を投げてくることはありません。
だっせｗｗｗｗ

> 書き忘れましたが言語はC++なのでAPIが例外を投げてくることはありません。
だっせｗｗｗｗ

535 ：

環境を何も書いてないから例外を投げないAPIなのかも知れんが、どんなんだろ。
あとはC++といいつつCのライブラリしか使わんとか。んなわきゃないか。

536 ：

C++といってもぷち強いCみたいなのも結構あるからな

537 ：

C++のnewが例外投げるわけだが。

538 ：

C++のコンパイルオプションで切り替えるのでは？

539 ：

例外は基本システムエラーだけど
catchして適切に処理を施して続行する時点で業務フローに組み込まれる

540 ：

システムエラーじゃなくて
実行時エラー。
実行時にならないとわからないものが例外。

541 ：

bad_alloc 受け取ったからって、アプリ側で何が出来るんだろ。
どうせプロセスごと落ちるなら後始末もへったくれもないし。

542 ：

> bad_alloc 受け取ったからって、アプリ側で何が出来るんだろ。
エラーログにどこでエラーが発生したか書き込むとか。

543 ：

その外人さんってリーナストパーズみたいな
C++はゲロ。低レベル開発はCこそ至上ってタイプのひとじゃないの？
例外投げると、オーバーフローとかthrowされない狭義の意味での
例外処理サボるから糞だと思ってるんじゃね。
多分暗黙の処理とかも大嫌いなんだろう。
>>541
キャッシュ用メモリの解放
応用として不要になってもbad_allocが発生するまでdeleteせず放置とか

544 ：

もうなんにもできないくらい追い詰められてるのと
一仕事しようと大きくメモリ確保しようとしたときじゃ
違うだろ

545 ：

だよね。
例外だと一律に何も出来ないと
決めてはいけない。

546 ：

>>543
個人的にだけど、C言語に極端に意識が慣れてしまうと、gcとか何かを完全に任せちゃってしまう
ようなものって逆に不安でさー。
便利だって意識より、俺の知らんところでこいつ一体なにやってんだろって気になっちゃう。
だから、頭では分かっていても使いたがらないというか。
例外も、自分でちゃんと処理書いてきっちりなにが起き得るのかを分かってて書いてしまいたい
という意識の方が強くて。普通の人ならいちいち書かないで例外任せにするようなチェックも
かいちゃうなぁ。まぁ、newとかで例外起きるとかってのは例外で拾うしかしゃーないけども。

547 ：

あ、ごめん。
最後の一文は「catchで拾うかスルーしろ」、のミス。

548 ：

>>531
try-catch無い場合は余計階層が増えるんじゃないか？
でないとgoto使わなきゃならんはめになる

549 ：

Javaはウンコ。
プログラマーと呼ぶべきかどうかも微妙。

550 ：

ほらほら、釣り釣り

551 ：

>>549
全面的に同意

552 ：

>>551
釣れましたｗｗｗｗｗ

553 ：

>>549
すこぶる同意

554 ：

こんな下らないことで
釣りとかレスの応酬とかするなよｗ

555 ：

>>549
同士

556 ：

>>550-555
お前らプロの釣りキラーだなｗ

557 ：

>>549
禿同

558 ：

>>549
マンセー

559 ：

>>558
お前だけは許さない。ぜったいにだ！

560 ：

ちょｗｗｗ　なんで俺だけｗ

561 ：

>>549
このレスを見たおかげで
もう医者から治らないといわれ絶望していた
腰痛がなおりました

562 ：

Javaもjavaだけど。
今のIT業界がおかしくなったのはJavaのせいじゃないのか？
プログラマーを猿にしたのはJavaのせいだよ。
正直、ホスト出身でもなれるくらいで、現場にいたんだよ。プログラマーも舐められたもんだと思った。
俺はまだC/C++,asmで食べてるけど、この分野は基礎がしっかりしてないと無理。

563 ：

IT業界（）

564 ：

(i)

565 ：

COBOL
MSBASIC
VB
Java
デスマ言語の歴史

566 ：

>>549
感動したっ

567 ：

素人でもできる、とかいう腐った台詞は40年前からある

568 ：

あいちーは一気に広まって土方と同じ状態になった
例外すら理解できないような底辺マが多すぎるのは、
技術がないのに技術者枠で身売りされてるのが原因
人売ってるだけで何もしないで中間マージン取ろうとしてる企業が多すぎる
発注元がもっとスキルを持って技術を知り、直接技術者を囲う体制が不足してる
どの道、今のスタンスのままじゃ、競争力がない日本は世界的に置いてかれるのが目に見えてる
悲しい

569 ：

士農工商からどう変転したものか、
「工」を社会の最低辺層と考える風潮が死なない限り日本の復活は無理。
そしてそれは、死ななきゃ治らない病気っぽい。
よって希望はない。とか思ってる。俺の死ぬまでは保ってほしいものだが。

570 ：

産業革命の労働者と同じ
過酷な環境と長時間労働と搾取
おまえらが教科書に載るんやで
むねあつ

571 ：

>>569
一応言っておくがな、
士農工商っていうのは、偉い順じゃねーぞ。

572 ：

まだ例外とかやってんだ

573 ：

uyか

574 ：

さっさとRばいいのに

575 ：

uyとかまだいたんだ

576 ：

いやいやほんと
半年くらいここ見に来なかったけど、
まだ例外とかやってたんだね
オブジェクト指向に関しては、否を唱えるスレも2chに出てきたけど
例外は未だに

577 ：

オブジェクト指向に関して否を唱えるスレを
見てきて分かったが、
オブジェクト指向がやっぱり現在一番
使える技術だよ。
例外もかな。
否を唱えている奴らが
こてんぱんにされてるのを見るとね。

578 ：

OOに否を唱えてる奴らは
そのOOではない設計手法に名前がついてないんだから議論じゃ勝てないよ
っつーか君、2chのこんなそこら中が底辺PGしかいないような場所で
議論で勝った程度でその決め付けはどうかと思うがね
君の世代では例外も使い続けるだろう
たくさん書いててくれ
それが次の世代の良い失敗例の良い模範となる
人は一度間違えた道を進みはじめても、そこを行き止まりまで行かないと気がすまない生き物だからね
行き止まりまでさっさと行ってくれよ

579 ：

OOは現在一番使える技術で間違いはない
万人に使える技術を採用しなければ、会社はアプリケーションを開発できない
俺が言っているのは、「OOの次」を見始めた奴がちらほら2chでも出てきたという事だ

580 ：

OOの次なんてものはない。
OOと共に。両方合わさっていく。

581 ：

OOは使い方によってはそこそこ使えるぞ。
前もお前に言ったが、間違えた抽象化や命名が混乱させてるから糞なだけで、最強ではないけど、正しく使えばそこそこだよ。
ただし、糞コード書くやつが多い。
糞コードは一目で糞コードだと解る言語の方が、混乱は少なく済む。
考えられてるのかとおもっていろいろ調べて観察した結果クソコードだったら書いたやつ頃したくなる。

582 ：

そもそもOOが構造化の延長だからね。
クラスやカプセル化、インターフェイス、隠蔽なんかは構造化と大きく被っている。
OO独自なのはオブジェクト間の関連に関する技術。
UMLやデザインパターンなんかだね。
継承や多態なんかもどちらかといえば構造化より関連に属する部分だろう。
例外は構造化プログラミングの範疇にあるものだと思う。
そういうわけでOOの次がくると言われて20年以上経つけど、それらしいものは未だ出てきてないので、俺が生きている限りは次はなさそうな気がする。
エージェント指向もOOの次だなんておこがましいものだったし。

583 ：

あんたが単に「分割して統治せよ」という大原則をわかってないだけ

584 ：

>>587が一体何に対して戦っているのか見えない。

585 ：

>>583の間違い。

586 ：

ひとつ分かってるのは再帰で書くと
ループで書くよりも記述量が少なくなったり、
変数が消せるって事
それを常に書いていけない理由は、人がバカだからとしか言えない
いずれ遠い未来使いこなせる奴が出てくると思う
そのときにOOはﾌﾟｷﾞｬｰｗｗｗといわれる

587 ：

ああ、糞コテ用隔離スレがなくなったのか。

588 ：

糞スレを立てまくったアホがいたからな。
糞スレ消化要員としてせいぜい煽っておこう。

589 ：

えー、再帰なんか普通に使うだろ。
どんだけスキルの低い職場なんだよ。

590 ：

鉄器時代のFortranで育ったジジイが幅を利かせてた時代には結構あったのよ。
（マネージャーが理解できないから）再帰禁止とかそういうルールが。

591 ：

>>589
じゃ、今日からOO捨てて再帰で書いてみっつって出来るんですか？
お前の考えてる部分の再帰の話じゃないよ

592 ：

おまいらにはスタックオーバーフローがお似合い

593 ：

なんで例外のスレでOO談義なんだ
Cに置ける構造化例外機構、C++の何でも投げられる例外機構、
Scheamの継続による例外機構、AdaなどPascal系の整数を投げる例外機構。
大半の例外機構じゃOOなんて関係ないだろ。

594 ：

uyはゲームが、ゲームがとやたら拘ってたが
そろそろまともに遊べるゲームの1つでもできたのか？
まさか、未だオセロとかそんなレベルじゃあるまいな。

595 ：

>>593
このアホコテは昔から
「例外≒OO＝悪」
という超シンプルな間違った知識しか持ち合わせていない
そこから全く成長していないから相手するだけ無駄

596 ：

その阿呆に釣られてOOの話を続けてる莫迦も
さっさと首括ってくればいいのに。

597 ：

マ板にはアホだろうがなんだろうが全力で相手する暇人が多いからな
他では速攻切り捨てられるから結局相手してくれるヤツが居るマ板に戻ってくるんよな
んで自爆するまで糞みたいな自説披露してしばらく沈黙
しばらくしたらヒキニートゆえに人恋しくなって(笑)またご来訪
この繰り返し

某スレに居着いてる別のレス乞食な屑コテも同様に
相手する馬鹿が居るからこの板に依存(笑)
攻撃されたらキレるが相手にされないと拗ねるのはこの子と同じ
まあそれなりに需要と供給が成立しているということなのだろう

598 ：

>>595
例外が悪とかいってないよ
オブジェクト指向（笑）やっていく上では例外に頼るしかないよね
それはどういうことかというと、
そもそもオブジェクト指向が斜めに立てられた建物であって
オブジェクト指向で大きなもの作っていくとどうしても
それを支える添え木として例外が必要になってる事に気づこうか
そもそもｗ　newで例外が発生するからプログラマがそこにコードかくとかｗｗｗｗｗｗｗ
･･･OSか言語設計見直せよって話じゃん
OSや言語が斜めに立てられてるから、プログラマは例外で添え木をするしかなくなっているんだよね可愛そうにね

俺もRubyで例外は使うよ
でも静的言語で使うような例外ではなくもっとシンプルな使い方
method_missingも例外みたいなもんだしね

599 ：

trycatchのどこにOOの入る余地があるのかわからん。

600 ：

Google Goや、純粋OOP型であるVisual Works、
Pharoに例外機構が無いのに何言ってんだ？
例外処理自体はするけど、Cの例外処理と
似たようなもんだし

601 ：

>>598
それより、ここ一年で何作ったんだよお前は

602 ：

プログラム関連でいえば
3つくらいは作ったかもしれん
いずれも1日で作ったものだよ
公表は出来ない類のもの
つーかプログラミングやってない
忙しいR

603 ：

例外なくてもOOは成立するだろ
何言ってんだこの馬鹿

604 ：

visual worksにもpharoにも例外機構はあるが…

605 ：

別軸のパラダイムを混同するなよ

606 ：

シェルスクリプトにも
例外相当のものがあるというのに。

607 ：

例外の考え方としては、
エラーが発生したらデフォルトで本来の流れと違うコードに飛ぶというもの
これの利点は、想定外の事例が発生した時に
（エラーってのは大抵想定外）、そのまま処理が進むないということ。
何も書かない状態で安全な動きをするというのがメリット。

608 ：

例外は第3の選択肢であって、想定していない事象を握りつぶすことじゃないよ。

609 ：

そりゃ想定してないのを握りつぶしたらダメだろw
なんでわざわざ握りつぶすんだ？

610 ：

>>604
参考にその例外機構を使ったコード書いてみて

611 ：

ぐぐれかす

612 ：

>>604
汎用的なシグナル・ブロック・通常のメッセージ式の組み合わせで
ライブラリとして例外処理出きるようになってるだけで、
専用の例外機構なんてなくね？

613 ：

なぜそんなものを作ったのか、
便利だからさ。

614 ：

>>609
Rubyで俺は、例外使うときにそういう使い方をしてるよ
利点としては、いちいちエラーの原因探るのがめんどくさいんだけど、なんか稀にエラーが出ちゃう場合に、
とりあえず例外で飛ばして次の処理にいく
そんなかなりアバウトなプログラミングが出来る
俺はこれを最近とあるマルチスレッドプログラミングで行った
500の何かがあった場合に、その中からエラーを出さずに使えるものだけ使い
ある処理をする場合にエラーの原因を探らずにプログラミングを続行するために例外を使った

615 ：

> 利点としては、いちいちエラーの原因探るのがめんどくさいんだけど
あぁ、俺も面倒くさい時は
信号無視とかやるよ。
でも今は、間違ったことをやるって話じゃないんだ。

616 ：

>>612
MethodContextのソース読んでみるヨロシ

617 ：

復旧できない例外を復旧できるところまでラップして投げたりするのは普通に当たり前のことだが、
理解できないから全部スルーすんのは間違いだろ。
バグの原因をもみ消し追跡を更に困難にする糞コードの典型じゃん。
結構長い間マ板に執着割りには、相変わらずuyは成長がないな。
昔から常に自分が優位だと思い続けるためだけに、主張コロコロ変えながら無駄レス量産続けてるだけで
プログラミングのスキルは全然身に付いてないじゃん。向いてないんじゃね。
それともチンコで釣りするのが趣味なのか？

618 ：

つか、必要だからそのルート通るんでしょ？何から問題があったとして
そこをぶっ飛ばすなんて、その先まともに動くのかね？よしんば動いたと
しても、それって自分で作ったもんをコントロールできてねーんじゃ？

619 ：

まだ例外使えない奴がいるのか。

620 ：

理解してる>>615と理解してない617,618の違いはなんだ
赤信号でもプログラムを完遂させるようなソースコードなんて
普通書く奴いないから無視していいよ
イメージとして捉えられない奴にまで説明する気もない
別にそれを例外の正しい使い方だとか言ってないしｗ

621 ：

> 理解してる>>615と理解してない617,618の違いはなんだ
俺がお前に教えてやるレベルだからじゃね？

622 ：

へー
ただ単純に結果だけがほしい時であれば
再現性が少ないエラーやバグを、いちいち調べないってのが本当の所
rubyだとgemで落としたらライブラリにバグもあったりするし、文字コード関連や型エラーなど
そういうものを、よく考えずにすっ飛ばしてどうにか動くようにする為に例外使うこともある
この使い方は、元々の例外の使い方じゃなくて副産物なんだろうね
けど便利に使わせてもらってるよ

623 ：

どうせ社畜プログラミングしかやってない子にはわからないんだから、
わからないものはスルーすればいいのに
2chの全部のレスから疑問をなくさなくちゃ気がすまないのか？
uyは何を言っているんだろう、よくわからないや　で終わらせればいいのに
邪魔だと思うぞ、そういうのは

624 ：

で、お前なんのために生きてるの？

625 ：

約束したんだ
あの日

626 ：

0点

627 ：

uyはコテンパンにされたコテハン

628 ：

http://x47img.peps.jp/uimg/m/marinesaona/14/cc33xqy144B.jpg

629 ：

>>628
お前は毎日日曜日だろ？ｗ

630 ：

>>620
やっぱりuyは馬鹿だな。全然理解できないじゃん
>>615,617,618は結局全部間違いの指摘だろ
あの>>614の内容じゃ、俺馬鹿ですよ叩いてくれって言ってるようようなもんじゃないか
それとも、今度もまた以前の発言捻じ曲げて、都合よく解釈して自己弁護するの？
> それともチンコで釣りするのが趣味なのか？

631 ：

今度はここでコテンパンにすればいいのか？

632 ：

糞コテは相手するだけ無駄だからスルーしとけ。
何言っても最後にレスした方が勝ちだと思ってるから、何かしら反応してくるし邪魔。無視が一番。

633 ：

存在自体が例外みたいな屑ニートが例外扱いはダメって
自分をドロップアウト扱いするなって言ってるみたいで笑えるよね

634 ：

throwしろって話かｗ

635 ：

>>623
>わからないものはスルーすればいいのに
そうやってわからない(理解できない)例外を全部スルーしてるってわけか
うちの数ヶ月で切られたゴミ中途も同じようなことしてたなｗ

636 ：

スルーﾜﾗﾀ
そっちの意味だったのか…。

637 ：

また暴れるようなら再度過去のイタい発言集をテンプレにした隔離スレをたてるだけだな

638 ：

例外が発生した時にその後の処理をすっ飛ばしたら問題だろ、
と言って例外を批判するやつは、例外を使わなくてもエラーコードをチェックして
その後の処理をキャンセルするコードをせっせと量産しているという事実を
見逃しているからフェアな比較ができてないだけ。
そしてエラー処理を入れ忘れてバグると。例外をつかったほうが逆に安全、というのは直感に反するところもあるが事実だ。

639 ：

うゆは基礎学力をつけることをスルーしてきたからなぁ。

640 ：

例外スレらしいオチも付いたところで、糞コテを補足して処理するのもこれくらいにしておこうか。
ここでは復旧できる見込みのない例外だし、ロギングもしたから再スローするのが正しい。

641 ：

>>614をしたり顔で書いてるの想像すると笑ってしまう

642 ：

周回遅れに気づけない

643 ：

他人にソフト公開してる訳でもないクソコテにつきあうお前らってやさしいな
そのままちゃんと隔離しといてくれよ

644 ：

思うんだけど、俺がレスをしないとスレ停止してんだけど
たのしいかこれ

645 ：

え？お前をからかうスレだろう？ｗ

646 ：

なぁに、スクリプトが止まっただけだ。

647 ：

元々過疎スレでたかが1日レスが無かったぐらいで何の問題が？

648 ：

診断基準（アメリカ精神医学会　DSM-IV）
『自己愛性人格障害』Narcissistic Personality Disorder
誇大性（空想または行動における）、称賛されたいという欲求、共感の 欠如の広範な様式で、
成人期早期までに始まり、種々の状況で明らかになる。以下の5つ（またはそれ以上）によって示される。
　（１）　自己の重要性に関する誇大な感覚（例：業績やオ能を誇張する、
　　　　 十分な業績がないにもかかわらず優れていると認められることを期待する）。
　（２）　限りない成功、権力、才気、美しき、あるいは理想的な愛の空想にとらわれている。
　（３）　自分が特別であり、独特であり、他の特別なまたは地位の高い人達に
　　　　 （または施設で）しか理解されない、または関係があるべきだ、と信じている。
　（４）　過剰な賞賛を求める。
　（５）　特権意識つまり、特別有利な取り計らい、または自分の期待に自動的に従うことを理由なく期待する。
　（６）　対人関係で相手を不当に利用する、つまり、自分自身の目的を達成するために他人を利用する。
　（７）　共感の欠如：他人の気持ちおよび欲求を認識しようとしない、またはそれに気づこうとしない。
　（８）　しばしば他人に嫉妬する、または他人が自分に嫉妬していると思い込む。

649 ：

>>638
＞見逃しているからフェアな比較ができてないだけ。
＞そしてエラー処理を入れ忘れてバグると。
処理書いてるからフェアかどうかって話ではないでしょ。
でもって例外だって例えばキャッチし切らずに抜けること
あるじゃん？でより上位の例外処理でつかんじゃって解析に
手間取ったり。
間抜けな話だがまぁそこまでいくと、どこ
までを処理の中
で想定できてるか、どこまで問題をとりのぞけるかっちゅー
話になってくるけどね。
一緒だよ。

650 ：

>>649
デフォルトで処理が止まるのと進むのと、どっちが問題を起こしやすいか、
問題が潜在化・深刻化しやすいか、考えてみたら違いがわかるでしょ。

651 ：

今ちょっと、
これから有名になって使われるであろうプログラミング言語の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のｗｗｗｗｗｗ博士級の人達がｗｗｗｗｗｗｗｗ例外はいらないと言ったんですねｗｗｗｗｗｗっうぇｗｗｗｗｗｗ

652 ：

そりゃそうだよねーーー
いらないよねーー
このあたりはJava（笑）と違って流石Googleかなって思う
＞クラスの継承
これもいらない、同意
＞ジェネリックプログラミング
これもいらない、同意　メタとか動的言語でやれって話
＞アサーション
は使ったこと無いな
＞オーバーロード
これは静的言語ではあると便利だけど、Goの構文だとやりにくかったんだろうな
別の方法が用意されるなら良い

653 ：

だから誰にも相手にされず消えていったわけさ

654 ：

しかし、角がなくて味気ないuyだな

655 ：

>>651
悪い悪い。訂正しておいたよ。
> クラスの継承、ジェネリックプログラミング、アサーション、オーバーロードといった機能が存在しないことも特徴として挙げられる。
> try-catchはないがそれに代わる機能としてpanicとrecoverを用いた例外処理をサポートしている。[2]
> FAQにおいて、ジェネリックプログラミングは一部導入が表明されているが、オーバーロードは効率的見地から排除されたことが述べられている。
> 関数は多値を返すことができるので、それによりエラーの報告は容易である、としている。

656 ：

英語版を参考に、もうちょっと追加したよ。
> クラスの継承、ジェネリックプログラミング、アサーション、オーバーロードといった機能が存在しないことも特徴として挙げられる。
> インターフェースを用いたポリモーフィズム（多態性）が実現されている。
> try-catchはないがそれに代わる機能としてpanicとrecoverを用いた例外処理をサポートしている。[2]
> FAQにおいて、ジェネリックプログラミングは一部導入が表明されているが、オーバーロードは効率的見地から排除されたことが述べられている。
> 関数は多値を返すことができるので、それによりエラーの報告は容易である、としている。

657 ：

Googleの中の人のプログラミングがダメダメなのは
Android携帯のできの悪さを見ればわかる。
例外だけでなくアサーションもないということは
それだけエラー処理を軽視している証拠。

658 ：

なんだ。Goにも例外あるんですね。

659 ：

インターフェースがあってクラスの継承がないというのを見ると
VB6を思い出すね。
VB6もシェネリックもオーバーロードもないし、
あ、でもアサーションはあったな。

660 ：

マ板でtypoする奴がいるってのが信じられない
マ止めた方がいいね

661 ：

Cの代替言語で何かする気にはなれない
そういうのは組込み屋がやってろ
ScalaやれScala

662 ：

COM

663 ：

Goのdefer文とpanic-recoverの仕掛けは実際良くできてるよ。
try-catchなんか実はfinally節が必要なだけな場合も多かったりするし。
とりあえずtry-catchで囲んどけ、みたいなことがないだけマシ。

664 ：

一番マシなのは「；」　末尾のこれがない事だろ
；　これ消すのに半世紀かかってんじゃねーよｋｓ

665 ：

貴様 awk を知らずに偉そうなこと言うな

666 ：

uyしっとるか
BASICは「:」打つと同じ行に次のステートメントを書ける

667 ：

てかfortranにんなもんねーよ

668 ：

>>655　どうでもいいがtry-catchだろうが、recoverだろうが例外処理って書いてるのおかしくないか？
こういうのは、あくまで例外機構であって、例外処理は人間が書くものじゃね。

669 ：

>>664
枝葉末節はいいから、他人に見せられるソフト作って公開しろよ
ソフト一つ作れん言語オタクの戯言なんざどうでもいい

670 ：

コードはよく出してるよなuyは。他人に見せられるかどうかは…

671 ：

すぐ例外と関係ないことに流れて自分の主張すら忘れる程度の知能しか持ち合わせてない
レスするほど価値があるか考えてから相手しろよ

672 ：

知能程度が近いんだろ。

673 ：

uyだしな
触る奴もアレ

674 ：

この会話の流れの脱線具合がいかにも例外っぽい。

675 ：

こんどはここでボコボコにされてたのかｗ

676 ：

C++だと、例外はファクトリメソッド内以外ではcatchしない
オブジェクト生成時に発生した例外だけはエラー戻り値に置き換える
それ以外の場所で発生した例外はアプリ殺した方がマシ
無意味なcatchをあちこちに配置する必要なし

677 ：

> オブジェクト生成時に発生した例外だけはエラー戻り値に置き換える
え？ newの戻り値が、エラーになるの？
ありえんわぁｗ

678 ：

つか、C++の例外は途中でCがはさまったりすっとややこしいからなぁ。

679 ：

>>676
えとね、コンストラクタで例外だしていいんですよ。
どっかの馬鹿本がだめとか間違ったこと
書いているのがいけないんだが。

680 ：

というかRAIIというベストプラクティスが一般的になる前に、「C言語禁じ手」っていう
べからず集の人気が出た勢いで書いちゃった、ろくにこなれてないC++べからず集に
書いてあったのが、その都市伝説化の発端なんだよな。

681 ：

あと、どこでcatchするかは処理次第だから、
catchするだけでNGというようなミスリードを招きそうな書き方はちょっと違う気がするな
アプリケーションとして続行可能だが、メソッドとしては例外、なんてのはいっぱいあるし
その処理で復旧可能であればその場でcatchすべきだし、
常に復旧できる処理であれば、例外復旧までを含めた処理作ってラップしてあげればいい
たまに湧く、例外に文句言ってる人は、こういったラップした処理しか作った/使ったことないから、
例外を吐く必要はないって思いこんでるんだと思うわ

682 ：

ラップされてるんならいいんだけど、ラップもせずに例外上げてくるのがむかつく。

683 ：

>>682 エラー処理めんどいってことだろ。わかるわかる。

684 ：

異常系考慮しないマほど例外を嫌うイメージ
なんか例外出たってことには気づくけど、その内容が理解できない奴も多い

685 ：

そもそも、知る必要ないものばかり投げてくるじゃん。
そういうダサすぎなプロジェクトばかりで嫌になる。

686 ：

確かに知識がないことを棚に上げて文句言ったりする奴が多いな

687 ：

>>685
たとえばどんな例外のこと言ってるの？
プロジェクト内の話ならお前がダサくないように修正を提案すればいいんじゃないの？

688 ：

例外クラス(値?)をどうデザインするか迷う。
構造がまったく同じで型情報のためだけに
クラスボコボコ作るのも面倒くさいしなぁ。
throw LexError<class Lexer::InvalidSymbol>( 色々 );
とりあえず、識別用の型をテンプレート引数に渡して
それで区別するってのが楽では有るけど、結局同じ型が
生成されてるのがなんかねぇ。

689 ：

JavaでWeb系なら、基本的にはRuntimeException継承した業務レベルのエラー1つだけにしておくかなぁ
システムエラー的なので、RuntimeExceptionじゃない奴は
共通処理で行うように設計して、理解してる奴に担当してもらい、RuntimeExceptionでラップして投げるようにする
とにかく馬鹿にはなるべく意識させないようにしておくのが理想

690 ：

>>688
同じ意味合いのある例外ならそういう集約の仕方はありだと思う
型が同じだと違和感があるような例外であるなら、元になる例外を継承して複数のクラスにする、とかでもいいと思う
普通にクラスを作るときと同じ感じで設計するのがいいんじゃね
同じオブジェクトとして扱うべきものかどうか、が判断条件
個人的には、クラスファイルが増えること自体は、全然面倒だとは思わない

691 ：

中身に文字列しか持って無いようなのが困るんだよね。
いっそハードtypedefがありゃいいのにと思うぐらい煩わしい
class CantOpenFileError:
　　public std::runtime_error
{
　　　CantOpenFileError( const char message[]):
　　　　　　std::runtime_error( message ){}
};
class NotExistFileError:
　　public std::runtime_error
{
　　　NotExistFileError( const char message[]):
　　　　　　std::runtime_error( message ){}
};

692 ：

try{}
catch(...){}
何でもかんでも全てこれ。
再研修受けるか、現場から去ってくれ。

693 ：

まず、お前がそういう研修を
されたかどうか考えてみ？

694 ：

転職して来た奴なんだが…。

695 ：

Cにおいて例外ってどうやって捕まえるんですか?

696 ：

signal

697 ：

戻り値 + errno

698 ：

え、
そういえばC++からCのライブラリ使うときに例外ってどうすんですか
書き直しですか

699 ：

はぁ？

700 ：

え、
そういえばRubyからCのライブラリ使うときどうすんですか
書き直しですか

701 ：

え、
そういえばCからアセンブラのライブラリ使うときにスタックってどうすんですか
書き直しですか

702 ：

アセンブラーのライブラリは、アセンブラーのライブラリだから多少面倒だろうな。
アセンブリで書いたライブラリならオブジェクトコードにしてリンクすりゃ済むが。

703 ：

DLLを使用してるアセンブラーなんて多く無いだろうから
大概スタティックリンクでアセンブラーの実行ファイルに
組み込まれてるだろうな
アセンブラーの実行ファイル内に入ってるライブラリを
取り出すのは骨が折れるぞ

704 ：

先日またやられたわ…
public String getHoge() throws Exception {
　try {
　　：(全処理が一メソッド内にかかれてるせいでとてもスパゲッティ)
　} catch (Exception e) {
　　e.printStackTrace();
　　return null
　}
}
こういうコード書きまくってる馬鹿がわいてひどい目にあった
底辺なおかげでソースレビューの習慣がないせいで、馬鹿が紛れ込んでしまうとマジ悲惨
そういう馬鹿に限って、コミット殆どしないようにために溜めたゴミクラスを
数十個一括でコミットして、実装の不都合を隠しやがるし、その実装でも例外もみ消して隠しやてやがる
だいたいこれじゃ絶対例外飛ばないし、throws節の意味もわかってねーだろ！

705 ：

>>704
例外書いてるのにスルーしろwww

706 ：

底辺会社には底辺社員が揃うってことか

707 ：

>>704
その馬鹿も、昨日今日沸いたわけじゃあるまいに。
誰が見ても駄目なコードを放置しておいたお前も悪い。
見れば一発で駄目だってわかるじゃないか

708 ：

日本語読めない方は書き込まないで欲しいもんだね

709 ：

>だいたいこれじゃ絶対例外飛ばないし
ワロアww
throws new Spoon();

710 ：

関係ないがthrowsにException書くのは、俺はありだな。
throws
　　　Exception,
　　　SAXException
みたいな感じで、例外を投げる箇所には具体的な例外クラス名と一緒に
Exceptionも書いておく。新しい例外を追加する際に非常に楽だ。

711 ：

やめろ馬鹿ｗｗｗ

712 ：

なぜ？

713 ：

検査例外である必要が全くない

714 ：

例外検査に必要なのは投げる可能性が有るか無いかだけ。
個別の型検査は、オーバーライドが有る以上邪魔なだけだ。
http://www.ibm.com/developerworks/jp/java/library/j-jtp05254/
C++でも例外に対し警告を出せるthrowの元になった仕組みがあったが結局使われず
投げない事をしらせる意味しか無くなった。挙句は、それせんようの構文までできた。
挙句.net環境においては採用されず、後続の言語にも採用するものは居ない。

715 ：

そういうのは実行時例外で事足りるだろう
意識させるための検査例外なんだから全部にExceptionとかアホの極み
ないわ
まあこの意識させる例外ってのは検査例外のダメな部分でもあるけれど
きちんと最初から例外も設計されてる環境なら、それが問題になることはそうない

716 ：

もうみんな匙を投げちまってるんだから今更言っても遅い。
Exceptionとまでは行かないまでも、SAXException、SQLExceptionと
ライブラリーベンダーは単一型でthrows定義して、必要に応じてcatch
細かい例外に別けろなスタイルを取ってる。まぁ、アレは失敗だよ。
throwsに細々派生型書くなんてスパープログラマーさんだけがやってりゃいい。

717 ：

検査例外自体、上まで投げ返すような使い方するもんじゃないしな。
なるだけ発生した直近で処理するのがベストでしょ。
んで、多発するようなのを個別に処理するのは面倒だし、
そもそも、知識ない人に例外意識させてもろくなことにならないから、
検査例外に対しては、共通の処理作ってはRuntimeExceptionの派生でラップするようにするしかないと思う。
そう考えると、無駄だなって気がするのもなんかわかるかな。
まぁ、ライブラリ導入して、ドキュメントとか見なくても、ラップしとかないといけない例外とかがコードだけですぐわかるのは利点でもあるけどね。

ともあれ、とにかくアホにはなるだけ例外を見せちゃいけない。
あいつら検査例外でビルドこけると、おまじないのようにthrowsExceptionとかcatch(Exception)とか書くし。
アホを除外できれば一番なんだろうけど、なかなかそうも行かないしな。

718 ：

ないわー、まじないわー。
catchないしthrowsを強制させるExceptionで通常のthrowsをまとめるならまだしも、
実行時の整合性エラー(RuntimeException)で代用するとかまじないわー。
ExceptionならIOExceptionとかなげる事もできるしcatchのチェックも維持できるけど、
RuntimeExceptionならチェックなくなって元も子もねぇじゃん。

719 ：

>>715
理想論はいいとして、throwsへの派生型記述にこだわると何が嬉しいの？
開発経験ながけりゃ派生型の固有の情報が欲しい時なんて必要に応じてぐらいで
毎回必要とされる機会なんて殆ど無いはずだが。

720 ：

開発経験の長い人で派生クラスだけをthrowsに書けって人は、
オーバーライド先で系統の違う例外が発生したらどうしてるの？
IOExceptionしかthrowsに書いてない場所でSQLExceptionが発生したら？

721 ：

全部のメソッドにthrows Exception書いてるプロジェクトは色々死んでた記憶しかないな

722 ：

珍しくスレ伸びてるね。
throwsにExceptionって書くのはチェック例外自体無駄な記述としてしか利用してないってことだから、
そもそもチェック例外のある言語を使ってる意味はないかな。
安いゴミグラマ簡単にかき集めれるって意味でJavaを使うメリットは十分あるけどね。

723 ：

>>721
どんな様子だった？
例外握りつぶす馬鹿が参加してたとかそんなオチはやめてね。
そういう馬鹿が居るのはは、チェック例外に限らず全般に言える問題だし。

724 ：

>>722
あるさ。例外を投げる。投げないって事は解る。
C++11にもそういう機能が登場したしね。

725 ：

無効な値を返す、または、オブジェクトが無効になる可能性がある→例外処理必須
値を返す場合は必ず有効な値を返し、必ずオブジェクトは無効にならない→例外処理不要
例外の委細は解らずとも、throwの有無が解ることには価値があるわな。

726 ：

RuntimeExceptionを祖先にもつ例外だってthrowsに書けるし、javadocにも書けるから、意識できないわけじゃないよ。
実行時例外と検査例外の差は補足の有無をコンパイラがチェックするかの違いだけ。
処理済みでかつ一部の共通処理以外では補足の必要がない状態になった例外までコンパイラーに検出させる必要ない。
なので実行時例外へ纏めてしまう、って手法は、汎用的なフレームワークとかでも使われてるよ。
むしろ後から例外が増えた場合に影響ないように、なんて理由で、親のタイプでthrows節に書くのは、
Exception型でcatchしたりすることが増える要因を作ったり、多数のメソッドに検査例外のthrows節が必須になったりして、
無用な補足を多数繰り返すようになったりしてNG。間違いを招きやすいので、これはやっちゃいけない。
そんなことをやってしまうと、とたんに検査例外の意味がなくなってしまう。
プライベートメソッドでthrowsで例外を伝播させていくとかであれば、一クラス内で収まるし大きな問題にはならないけど、
protected や public メソッドでそれをやるのは、やっぱよくない例外設計だよ。
そういうのが蔓延してしまうと、不必要な補足をされてしまった場合に、機械的に検出するのが難しくなる。
チェック例外のビルドエラーを発生させないように記述する方法はいくらでもあるからね。
一部の共通の例外処理を除いて、catch(Exception e) のようなコードに記述させないルールのほうが、
徹底しやすく機械的な発見もしやすいから、意図しない例外処理が発生する要因を減らせる。
このあたりの使い分けに方ついては、別に最近出た話題でもないので、情報は結構あるよ。
ttp://www.google.co.jp/search?q=%E5%AE%9F%E8%A1%8C%E6%99%82%E4%BE%8B%E5%A4%96

727 ：

>>721
それは、実装ではなく設計の問題じゃないかな？
継承をすることでメソッドの役割や機能が変わってしまってるので、祖先のメソッドが限定的過ぎたか、
子孫のメソッドが異なる役割を持ったメソッドになってる、ってことが本当の問題だと思う。
事前に集約されたタイプでの throws に"しておく"のは、
そういう問題が起きたとき、場当たり対応しやすいようにするためのアンチパターンでしかないよ。
もちろん、集約したタイプでの throws 節を書くな、という意味ではないよ。
>>724
検査例外は、例外が発生するしないを伝えるためのものではなくて、
その例外の補足の必要があるかどうかを、必ずコーダーに判断させることを強いるためにだけ、使うべきだと思うよ。
なので、アプリケーション全体で、処理済みであったり補足の必要がないのがわかりきっている例外まで、
検査例外でビルドが通らないようにしてしまうのは、検査例外である意味をなくしてしまってる。
そして「ビルドを通すようにする」という本来の目的ではない理由で、
例外の補足か伝播をハードコーディングする必要が出てきてしまう。
例えば、ぬるぽやIlligalArgument、UnsupportedOperationなんかが実行時例外になってるのも、同じような理由。
これらが発生するのは、基本的にコーディングのミスによるものなので、普通は補足しちゃいけない。
補足してｶﾞｯするのではなく、発生しないようにコーディングで回避すべきことだしね。
同様に、処理すべき場所が明確に定まっているような例外であれば、関係のない場所で勝手に処理されてしまうのはバグ。
しかし、関係のない例外処理が随所に入るような例外設計になっていると、それを機械的に見つけるのが難しいくなってしまう。
検査例外がない言語であれば、例外処理をしている箇所を抽出すれば勝手な処理を発見できるけど、
先に書いたような、ビルドを通すためだけの例外処理が随所に出てきてしまうようになっていると、抽出が難しくなっちゃう。
だから検査例外が無駄になってるって話だと思う。

728 ：

あ、呼びもとの例外処理を意識した例外のスローが云々は勿論理解しているよ。
ライブラリのような再利用が前提のモノに関して、実行時例外で纏めるのはどうか、
みたいな話、一々言わなくてもわかるよう事なので端折ってます。
実行時例外で集約云々のくだりは、
同一のアプリケーション内でお互いを全く意識しない前提な実装にするのは、
再利用性は高まるだろうし、こうあるべきって姿なのかもしれないけど、
そのアプリケーション以外でも活用するものでない限り、ただの無駄になる、という考えです。
それに、実行時例外でのラップを前提とした例外処理まで含めた
フレームワークとして再利用するのであれば、再利用も出来ないわけじゃないしね。

729 ：

>>726
RuntimeExceptionを代わりにつかうのはアンチパターンだよ。
普通バグかランタイムシステムの異常だからね。
>なので実行時例外へ纏めてしまう、って手法は、汎用的なフレームワークとかでも使われてるよ
実際のクラスドキュメントへのリンクを貼ってくれるかい
>>727
理想論はいいんだけどさ、具体的にどいう風なコードでどういう問題が発生するか書いてよ。
Exceptionでthrows指定した時点で理想は捨てて実利をとりに言ってる訳だから。
>なので、アプリケーション全体で、処理済みであったり補足の必要がないのがわかりきっている例外まで、
>検査例外でビルドが通らないようにしてしまうのは、検査例外である意味をなくしてしまってる。
>そして「ビルドを通すようにする」という本来の目的ではない理由で、
>例外の補足か伝播をハードコーディングする必要が出てきてしまう。
例えば、実際にはこういう問題は起きないでしょ。

730 ：

throwsにException型を書くのはその問題の典型じゃねｗ
めちゃくちゃ見かけるわ
あれ、このシステムではチェック例外を一切利用しないという宣言だろ

731 ：

try{・・・・}
catch( RuntimeException exception ){ throw exception; }
catch( XxxxxxxException exception ){ /* Xxxxxxx固有例外処理 */ }
catch( Exception exception ){ /* 一般例外処理 */ }
これだけの事だろうに、なんで>>730みたいな話になるんだ？
単に教育が悪いだけじゃないか？

732 ：

RTEキャッチして再スローとか随所に書く必要があるとかアホだなー

733 ：

RuntimeExceptionにねじ込んでcatchできなるくなる事に比べたらその程度の手間は気にならないよ

734 ：

斜めにしか読んでないけど、例外処理は絶対にこうしないといけないっていう厳密な縛りはないから、
用途やメンバーに合わせて、開発のチーム内で徹底できるルールを敷くことが大事であって
使い方は便利で問題が出なければ、ある程度柔軟に利用するのがいいと思う
道具は道具、アンチパターンにもメリットデメリットは存在するし、変に拘って視野を狭めないほうがいい
ただ、void hoge() throws Exception {} って書くと、それを呼び出す多くのメソッド全部が
throws Exception を書くハメになるから、普通は専用の例外を用意してそれでラップすると思う
Exception型を多用するのはデメリットのほうが多いし、Exception型使用禁止のプロジェクトとかもあるっちゃある

735 ：

小さいプロジェクトなら追っかけりゃ大体わかるしあんまり気にならないけど
大きいプロジェクトで無駄な検査例外あちこちにあるとハゲるからやめろ！
javadocみればわかるかと思ったら、
* @throws Exception 例外
こんなんかかれてたりしてマジハゲる！髪返してほしいわ…

736 ：

Exceptionをthrowsに入れるのはRuntimeExceptionで投げるのと変わらないって人は、
↓のような例外の要、不要なメソッドを分けられる事についてどう思ってるの？
RuntimeExceptionでも同じ事ができるの？
// finalで例外を出さない( コンストラクターでも同じ )
example.thomethingA();
--------------------------------------------------
try
{
// finalではなくオーバーライドされてる可能性がある
// また、throws Exception,・・・で宣言されいる
     example.thomethingB();
}
catch( RuntimeException exception ){ throw exception; }
catch( Exception exception ){ /* 一般例外処理 */ }
>>735
人間的な問題は現場の教育次第だし不毛だから置いとこうよ

737 ：

ハゲに不毛とか酷いなお前ｗ

738 ：

やっちゃいけないといえば、メソッドの最初でtry書いて最後にcatch書く奴とかもあるなｗ
Exception型投げてくる奴多数あると面倒だからそう書いちゃうけどｗｗ
>>737
だれうまｗｗ

739 ：

べ、べつに毛がないわけじゃないぞ…！
>>736
実行時例外ラップの話って、そもそもExcepton型でのキャッチや実行時例外のキャッチはさせない設計が前提の話じゃね
その場で捕まえないといけない例外はそもそも処理してまとめてから投げるか、
適切に復旧してもみ消して外に投げないから、派生クラスで限定的に書いても問題ないのでは？
色々ごっちゃになってね

740 ：

>>735
細かく書けるなら書くに越したことはないけど、
オーバーライドで変わる場合はコメントに何を期待するの？
この辺は結局、インターフェースを実装する側に合わせるんじゃなくて、
使う側の都合でコメント書くしか無いんだろうな。
「この@throwsに書いてある例外がなげられる」じゃなく
「この@throwsに書いてある例外は呼び出し側の処理に使用される」ってな感じ？

741 ：

つかなんかこう視点が違うな
全体の設計的な話してる奴と個々のクラスの実装担当者みたいな視点で話してる奴とじゃ噛み合うわけない罠
あとは想定してるアプリケーションも違いそう
Strutsとかつかってやるようなウェブアプリケーションと、その場で復旧して処理を続行するような落ちないシステム、みたいな
なんにせよ>>734、プロジェクト内でちゃんと統一が取れててハゲの原因を生まなきゃ何でもいいさ

742 ：

>>740
javadoc勉強しなおしな
@throws には型とその例外がスローされる原因なり条件なりを書くもんだ
インターフェイス仕様のドキュメントなんだから、何をしたら発生するかっていう仕様を書くだけ
まぁjavadocちゃんと書けてる奴って、実際あんま居ないけどな…
あとオーバーライドしたらインターフェイス仕様変わるとか、そのクラス設計のほうに問題あんだろ

743 ：

try {
　　：
} catch (Exception e) {
　　e.printStackTrace();
}

744 ：

>>742
「」の中はコメントの内容言ってるんじゃないよ
throwsに列挙される例外の条件を言ってるんだよ

745 ：

>>743
禿げる環境の話はもういいって

746 ：

>>739 例えば、こういう処理にそのRuntimeExceptionの設計思想を入れるとどうなるの？
@Override
public final PaintContext getPaintContext()
{
　　if( null != context ) return context;
　　try
　　{
　　　　PaintContextPrototype prototype = environmentDependentContextFactory.createPaintContextPrototype();
　　　　・・・略・・・
　　　　context = prototype.createPaintContext();
　　}
　　catch( RuntimeException exception ){ throw exception; }
　　catch( XxxxxxxException exception ){ /* Xxxxxxx固有例外処理 */ }
　　catch( Exception exception )
　　{
　　　　context = createSafeIndependentContext();
　　　　・・・略・・・
　　}
　　return context;
}

747 ：

{}の位置とか()内のスペースとかなんか気持ち悪い

748 ：

うむ、括弧のスタイルは統一してくれ
聞かれてないけど俺は括弧は括弧だけの行にする（{}のこと）

749 ：

こういうへんなコード書くおっさんがうちの職場にもいるけど例に漏れず例外も正しく使えてないな。
頭固いのか共通のフォーマッター使うように言われてるのに頑なに拒み続けてて最近空気が悪いｗ。

750 ：

あと、人のソースに手を入れる時に、はじめに作った人とは明らかに異なるスタイルで追加する人いるよな
あれ、マジでみにくいからやめて欲しいとおもう

751 ：

とはいえあまりにヘンな俺様ルールには従ってられないじゃん
たとえば746みたいな本人はこーゆーのが読みやすいと思って派手にRーしてるヤツね
おそらくはブロック内処理が2行以上なら改行して…みたいな一応決まったマイルールがあるんだろうけど
そのルールを推測する時間がもったいないじゃん？
触る前にフォーマッタかけちまうよ(ウチは使用を強制されてはいない)

752 ：

まともな意見もだせず関係ない話で叩こうとする
嗚呼これがパソコン大先生の遠吠えというやつか

753 ：

>>751
ブロックが横に続いてんのは2chだからだと思うぞ

754 ：

どうでもいいことに反論するのもアレですが、
一応癪に障るので言っておきます。{ throw exception; }こういう書き方したのは
単に書き込み行数を減らすためです。()のスペースとインデントに合わせた
ブロックの配置は割と一般的な方法でしょ。職場でもC系ならどの言語でも
使える点と、言語に依存しないフォーマッターならどれでも対応してる点、
誰が書いてもブレにくい点から規約になってたりします。

755 ：

反論するってことはどーでもよくはないんだよ
ここまでの流れみてて、細かい事例出して例外云々語ってんだなみんな、って印象
プログラム三原則とかに照らし合わせて作りゃいいんじゃないの？

756 ：

>>746とかイラッつとするわｗ
http://kohada.2ch.net/test/read.cgi/prog/1338703896/l50

757 ：

この程度で読みにくいとかイライラするようなプログラマはいらねーな。
レベル低い

758 ：

これは確かにイラっとするなぁｗ

759 ：

>>758誤爆
向こうに書いたつもりだったわｗ

760 ：

俺は>>746の書き方に似てるから叩かれてる理由がわからんな
統一してくれって書いてるやつがいるが統一されてるし

761 ：

>>760
ストライクゾーンの違い、それだけのことだよ

762 ：

>>746
>>754
＞{ throw exception; }こういう書き方したのは 単に書き込み行数を減らすためです。
javaは知らんが、C#の場合
http://d.hatena.ne.jp/aoki1210/20091007/p1
↑
みたいな話がある。

763 ：

こういう勝手をやるのがMSのダメなとこ
catchの中にtry〜catch書かれたときに
throw;なんてされたらさっぱりわからん

764 ：

>>762
C++の構文をそのまま持ってきてるだけだけどな

765 ：

>>763
げんごしようをりかいしてないことがもんだいなのでは？

766 ：

>>765
Vistaを理解してないことが問題
Excel2007を理解してないことが問題
とか言ってるのと同じだろ。ダメなもんはダメなんだよ

767 ：

理解してないことが問題だと思う人は、理解せず使えるものを使えば良い。
車に乗るといっても理解を必要とするF1に乗る必要もタンクに乗る必要も
パワーショベルに乗る必要もない。一生一般車だけ運転してれば良い。

768 ：

Vistaの不満もOffice2007の不満も、どっちも理解力がないゆえにの部分が大半だけどな
言いたいことはわからんでもないがたとえが悪いだろ
なんにせよ変化に対応できない奴はマには向いてない

769 ：

道具を理解しないで許されるのは素人だけだろ
請け負った仕事をしくじって使った道具を
理解出来なくてじゃ許されんだろ

770 ：

>>767
＞理解してないことが問題だと思う人は、理解せず使えるものを使えば良い。
普通「理解してないことが問題だと思う人」は、理解してから使おうとするんじゃね？

771 ：

理解にかける時間が妥当かどうか判断してからどちらにするか決める

772 ：

そら、PC使ってるからCPUの仕組みを理解しろとか、半導体物理理解しろって言われたら、理解しなくてもいいだろうけど
マやってて例外理解しろって言われたら、（言われてる時点で恥だが）、理解するしかねーだろよ

773 ：

ローカル変数を理解しなかった連中の末路を知らないのだろう

774 ：

>>769
難解な新製品を使わずに
手慣れた製品を使えば良い仕事はできる

775 ：

>>765
少なくとも、>>746はJavaの言語仕様理解してるし、JAVAで書いてるんだから何の問題もない。
恐らく、>>746であれば、C#で書く場合、ちゃんと>>762の仕様も理解して守ろうとするだろう。
全然問題なし

776 ：

もう弄るのは許してやってくれ
スレチ引っ張りすぎ

777 ：

C# ほとんんど知らなかったから勉強にはなった

778 ：

2chMate使うとよくぬるぽが出るのをどうにかしてほしい

779 ：

http://toro.2ch.net/test/read.cgi/tech/1346919580/549-554
例外を正しく使えないプログラマ

780 ：

話題の発端は、ここで語るような内容でもないから要らない誘導だろ
誘導元スレのほうでスルーしときゃいい

781 ：

多いね。とても多い。
まともに使える人がいなさすぎて、ユーティリティとかでthrows書いたら
catch(Exception e) とか書き出す馬鹿出たりするし、
基本的に共通の実行時例外にラップしたりして使えないマに例外を触らせないようにしてるわ

782 ：

Javaの検査例外は最近使わない事のほうが増えてきたな
馬鹿にはthrowsかかせないcatchさせないの、すごく重要だと思う
うまく使えば便利だけど、全員の知識がある程度の水準に達してる前提だから
うんコーダー混じった時点でその前提が崩壊する
で結局意識させない書かせないが最適だと思えてくる

783 ：

使えないのが例外だけなら良いんだけどな。

784 ：

お行儀の良い使い方ではないけれど、処理抜けを行うgotoとして例外をつかったフレームワーク、
なかなかキてる感あって、嫌いではないなって思った。
本来の意味での正しい使い方ではないと思うけど、
如何にして楽に作るかを突き詰めていけば、こういうのはありかなと思う。

785 ：

>>784
構造化じゃ書けないエレガントさってあるよな
Switchの流れ落ちとか

786 ：

構造化じゃ書けないとか言いながらswitch文使うとか、意味不明

787 ：

cだとswitchのcaseブロックはbreakしなければ下のcaseに流れ落ちることができる
c#などではこれは構造化の観点から禁止されている

788 ：

「構造化の観点から」じゃなくて、しばしばバグの原因になってるから、という理由。
Go言語は、fallthrough文を書けばfallthroughする。

789 ：

C#のswitchではfallthroughの代わりに、
goto caseをサポートしている。
fallthroughが次のcaseにしか移動できないのと違って
goto caseは任意のcaseに移動できる。

790 ：

例外じゃないけど、goto case、便利だよな
あんまり見通しよいコードになるわけじゃないから多用するものではないけど

791 ：

フォールスルーを構造化の観点から禁止するなら、
そんな機能を追加するはずがないよなw

792 ：

UMLで例外を一生懸命書いてるバカが居たな。
言いたいことは分かるが実装をモデリングすんなよ。

793 ：

なんのためのモデリングツールか理解出来ないうちはあんまり役に立たないね
改めてオブジェクト指向が何なのか、MVC、ドメインモデルってどんなのか
みたいなのを勉強しなおしてやっと見えてきたかなーって気がしてきた

794 ：

例外処理は急ぎの仕事の時に助かるぐらいのつもりで使ってる。
そして、だんだんメンテナンスムリーなコードが出来上がる。

795 ：

例外処理って昔の言語にはなかった
比較的新しい機能なんだぞ？
なんで新しい機能ができたかといえば便利だからだ。
なんで便利なものを使ってメンテンナンス無理なコードになるんだ？
それはお前の各コードが悪い。例外処理ではなく、
単にお前の技術力が低いってことでしかないんだよ。
例外使ったらエラー処理がめちゃくりゃ楽になるんだがねぇ。

796 ：

例外で重要なのは例外そのものではなくてその後のfinallyブロックだと思うｗ

797 ：

もう例外なしじゃ生きてけない
いちいち戻値のチェックするとか、原住民の生活って感じ

798 ：

>>796
finallyなんて大した機能じゃねーよ。
例外で重要なのは、関数コールスタックを
（途中でキャッチしない限り）
自動的にさかのぼるという機能。
finallyはガベージコレクションなどの
スコープ抜けたら自動的に後始末してくれる機能が
あれば殆ど使わない。

799 ：

GCは「スコープ抜けたら自動的に後始末してくれる機能」じゃないし

800 ：

> ガベージコレクションなどの
など
など
など
など
などが見えない？

801 ：

>>799
http://ja.wikipedia.org/wiki/%E3%82%AC%E3%83%99%E3%83%BC%E3%82%B8%E3%82%B3%E3%83%AC%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3
ガベージコレクション（garbage collection; GC）とは、
プログラムが動的に確保したメモリ領域のうち、
不要になった領域を自動的に解放する機能である。

802 ：

後始末が不要な言語、
不要にできる言語だと、
finallyは殆ど使わないよね。

803 ：

斜め上すぎてどう突っ込んだらいいのかさえわからないレベル

804 ：

>>803の意訳
突っ込みたいけど突っ込めない悔しい。
と皆思っただろう。

805 ：

オマエの脳内の皆とかどうでもいいいから…

806 ：

突っ込みたいけど突っ込めない悔しい。
は否定しないんだなｗ

807 ：

>>800
スマートポインタを指して「ガベージコレクトなど」と言うのは、
イギリスを指して「フランスなど」というようなものだぞ。
で、それを指摘されたら「ヨーロッパを知らないのプゲラw」って言うようなw

808 ：

どこにもスマートポインタの話なんか
でてきてませんが？

809 ：

突っ込みたいとかなんとか、卑猥な話題してんな…
Javaでいうなら7以降のAutoClosableはとても便利になったな
やっとusingっぽい事ができる様になった。これでうんこなfinallyのtry/catchみたいなのともバイバイできる
まぁ、仕事でjava7以降が使える日はまだ遠そうな職場だから恩恵ないんだけどな…(´･ω･`)
---
例外は機能制限されたgotoだから、うまいこと使えない奴がいるとおかしな事になるってイメージだなー
あと、ポリモーフィズムとかそういうのすら知らないような人が基板部分関わると、例外設計がかなり糞い事になってメンテ死

810 ：

例外キャッチして数値フラグや文字列フラグで返す処理を量産する馬鹿がいたり
クラスを上ってくるたびに例外捕まえまくってログだけ吐いて投げ直す処理を書いてたりとか、
そういう失敗例も未だにちょいちょい見かける

811 ：

例外を使えるプログラマは例外的

812 ：2013/09/17

ライブラリがせっかく理想的な例外を出すのにそれを俺様流でぶっ潰すのがうまい奴が大杉