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

1 ：2011/05/29 〜 最終レス ：2012/10/16

例外にまつわる内容であれば、不満でもネタでも主張でもご自由に。
@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 例外機構;
そもそも根底にあるのはタダの例外機構。
機構自体は、何ら例外の主体ではない。

100read 1read

1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

【逆に言えば・・・】プログラマの好きな名言0x02 (363)
正社員で派遣(常駐)されてる奴は目覚めたら？ (472)
アセンブラ言語やマシン語は覚えておくべきですか？ (351)
強制残業を無くそう part3 (253)
■自宅待機プログラマが自宅から集うスレ 6ヶ月目■ (508)
例外を正しく使えないプログラマ多いね。 その7 (778)
--log9.info------------------
ＤＱＮ輩中古車店主、汲み取りプレハブ物語 (294)
生活保護のキチガイが乗ってそうな車 (358)
千葉県にあるCSオートディーラ (484)
東京トヨペット　Ｕ・parkを語るスレ　１台目 (206)
【UC/CP】インスパイアpart9【お断り】 (311)
【240・760】中古ﾎﾞﾙﾎﾞでﾏﾀｰﾘ【850・960】6台目 (918)
★埼玉の中古車屋　U-P○RK★ (605)
中古車を買ったらこれだけはしとけ (561)
◆プレハブ小屋・汲み取り便所中古車屋専用スレ◆ (668)
【輸入車】ホワイトハウス・グループ【中古車】 (728)
中古韓国車総合スレッド １１ (931)
■　　　　登録済未使用車　　　　■ (439)
オペル総合スレ (485)
【【【【【【中古は損】】】】】】 (451)
★　★　★　車両保険　★　★　★ (431)
☆　ネクステージ　系列　☆ Part4 (216)
--log55.com------------------
モ子ちゃん
【モデルエース】SFホラー輸入プラ【ワイルドボア】
スターウォーズのプラモデル　バンダイ他 Part.4
☆Ａrmour Modelling57★
メッキ塗料総合スレPart2
コトブキヤのスパロボOGキットを語るpart41
模型戦士ガンプラビルダーズプラモ総合スレ8
模型イベント総合スレッドPart15