1 :仕様書無しさん2011/05/29(日) 14:17:29.97
例外にまつわる内容であれば、不満でもネタでも主張でもご自由に。

@throws Threadが100を超えましたException
   スレッドが埋まってしまった場合に送出されます。
   >>980 を超えたら新しいスレを準備してください。

@see 前スレ
   例外を正しく使えないプログラマ多いね。 その6
   http://hibari.2ch.net/test/read.cgi/prog/1298059471/
2 :仕様書無しさん2011/05/29(日) 14:46:27.66
>>1
Java前提にすんのやめろよ。
91 :仕様書無しさん2011/06/30(木) 01:54:06.40
続き

ただ、俺が>>85で言いたかったのは>>1を無視してまで騙る必要がこのスレに
あるのかってこと。
4 :仕様書無しさん2011/05/29(日) 15:00:57.36
javadoc形式のタグは他言語でも似たような形式で流用されてるの多いしJava前提ってわけじゃなくね
他の書式はXMLドキュメントくらいしか知らんけど

javadocといえば、@throws タグで例外の説明んとこに
「例外を発生させます。」とか「例外が発生した場合。」
とか書く奴が結構多いんだが、これも正しく使えない奴の所業だよな

全く持って説明になってないから、結局何が原因で例外投げるのかがわからないっていう…
勘弁して欲しいわ
5 :仕様書無しさん2011/05/29(日) 15:02:57.48
まともなコードヒントが出ない場合、発生する例外がわかりにくくて手間かかるわ
6 :仕様書無しさん2011/05/29(日) 19:34:21.83
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 */
{
}

ここからドキュメントを生成できるようにしろ。
ちょっと冗長になるだろうが、/** */じゃなくてアノテーションでもいいぞ
17 :仕様書無しさん2011/06/04(土) 01:50:25.75
>>16
うん。だから>>6-7のように
コメントとコードが一体になる方がいいと言ってるわけだ。
19 :仕様書無しさん2011/06/04(土) 11:17:10.25
>>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点目。
スレタイの「例外」に全く関係ない。
22 :仕様書無しさん2011/06/05(日) 01:12:31.83
>>19

お前はピントがズレていると言ったが、
本当にピントがズレているのはお前の方だ。

コードの中身に文句をつけてどうする。
それはあくまでサンプルであってコードに意味はない。

別にコードの内容を指摘されて悔しいから言っているわけじゃないぞ。

なぜならそのコードはwikipediaから拝借したコードだからだ。
http://ja.wikipedia.org/wiki/Javadoc
24 :仕様書無しさん2011/06/05(日) 02:06:38.87
引用元がどこだろーと、下手なコードが下手なことに変わりはないなw

コード批判はしてるかもしれんが、より本質的には発想批判だろ。
>>6の思考は、同じ名前二度書かせるな→まとめて書いちゃえ
というのが中途半端なんだよ。
コメントなくても通じるコード書けば十分だろ?っていう指摘。

doclet捨ててなおAPIドキュメント作りたいんなら、わかりやすいコードだけ書いて
リフレクションでAPI生成してろよ、
って普通思うんじゃねーの。
無駄だって問題提起しながら、そこで出した解決策がこれまた無駄だから揶揄されてるんだろ。
45 :仕様書無しさん2011/06/05(日) 04:19:54.44
で、どちらにしろコメントが不要になることはなく、

コメント書くならば、一箇所だけに書けばいいわけで
コメントとコードが分かれていると
同期を取らないといけなくなるから
一つにしろというのが>>6-7なわけだ。

あ、コードの中身はwikipediaの
JavaDocからの引用だからね

52 :仕様書無しさん2011/06/05(日) 12:27:14.03
で、関数名で分かるようにしろと言ってるだけで、
結局そもそもの問題。関数の引数とそのコメントの二箇所に
同じ名前が書いてあるのは無駄だから統一しろという
>>6-7の話をすり替えてるだけなわけだ。
9 :仕様書無しさん2011/05/30(月) 01:06:09.19
つか元々言語とは別もんの機能なんだから、
IDE辺りがコメントの同期をサポートするのが筋だわな。
言語に依存関係に無いはずの別システムのサポート組み込むなんて
ガラパゴス電話の失敗と同じ。
14 :仕様書無しさん2011/06/04(土) 00:27:22.12
>>9
どんな古いIDE使ってるんだw
時代遅れにも程があるぞ
15 :仕様書無しさん2011/06/04(土) 00:51:20.34
>>14
コメントを変えると同時に引数名が変わったり、
引数が削除されるIDEがあるのか最近は凄いな。
10 :仕様書無しさん2011/05/30(月) 01:24:34.00
> 言語に依存関係に無いはずの
いや、コメントは依存関係ありまくりだろw
11 :仕様書無しさん2011/05/30(月) 01:57:31.16
 コメントの内容は依存したらいけないだろ。
TCPのデータ領域をTCP階層で監視するようなもんだぞ。
もしjavadoc以外の高性能なツールがでてもjavadocへの
言語サポートが干渉してJavaではそのツールを使えなくなる。
javadocの内容をコメントから外してアノテーションのプラグマとして管理するなら別だろうけど。
13 :仕様書無しさん2011/05/30(月) 07:15:12.96
>>11
>コメントの内容は依存したらいけないだろ。
本来そうなんだけど、PostScriptってページ記述言語が有ってじゃな…

>TCPのデータ領域をTCP階層で監視するようなもんだぞ。
FTP...
IPv6に成ったら、FTPは撲滅して、scpかbit torrentに移行すべきだな。
12 :仕様書無しさん2011/05/30(月) 02:06:01.57
連動も面倒もどうでもいいから
発生する例外の詳細くらいはちゃんと書いておいてください><
16 :仕様書無しさん2011/06/04(土) 01:15:13.81
コードで表現できてるのを、コメントで二度書ききなきゃならないコードを、プロは書かない。DRYに反する。素人の糞コード。
コメントで言い訳書かなきゃならんコードをプロは書かない。それを設計とコードで表現する。

クライアントへの契約、を表現するドキュメンテーションコメントのこと言ってるなら、それはIDEがリファクタリングで連動して変換する。手作業の出番なんかない。

めんどくさい手作業をしにゃならん、と感じる状況を手作業でせっせっと勤勉にやってる時点で石器時代の土人。どんだけゆるい思想やプライドで職業ついてんだ、
発想の根本がこの業界にむいてない。
20 :仕様書無しさん2011/06/04(土) 11:43:56.74
コメントに「何をするコードか」ばかり書いちゃう奴は修行が足らん
そんなのは命名センスや設計センスがしっかりしていれば、最小限で済む。

それよりコメントには「なぜそのコードが必要か」に重点が置かれていないと意味がない。
最悪「何をするコードか」はコード読めばわかるのでわざわざコメントにかかんで良い。
23 :仕様書無しさん2011/06/05(日) 02:02:18.24
コメントというか、関数名の頭に描くべきものは、
例えばman sprintfをして表示されるようなものだ。

つまり、関数の引数の説明とか、
戻り値とか、そういう言うものを書くべきだ。
関数の頭にね。
25 :仕様書無しさん2011/06/05(日) 02:13:46.31
> コメントなくても通じるコード書けば十分だろ?っていう指摘。

コードはコメントがなくても通じるかもしれんが、
引数はコメントがなければわからないぞ。

お前は経験がない。知識だけでものを行っとる。

26 :仕様書無しさん2011/06/05(日) 02:15:25.48
特に戻り値は型しか書いてないから、
名前で意味がわかるなんて不可能だな。
30 :仕様書無しさん2011/06/05(日) 02:24:07.18
>>26
それはプリミティブで返すからだろ。
エリックエバンスの本とかにも分かりやすい説明あるぞ
27 :仕様書無しさん2011/06/05(日) 02:22:10.58
それは、名前の付け方が悪いんでねーの?
ってこと。
コメントで書く説明を、書かなくていいよーな引き数名にすれば済むでしょ。
そーいう発想で書いてみ?
キチンとしたコードが書ければ、「おいおいコードに書いてあるだろ?」って
コメント書く時間が無駄に感じるから。

で、コメントにはコードの説明なんかアホらしくて時間の無駄だな、ってのがスタートラインだ。
当然、コメントにはもっと別のことを、書く。
32 :仕様書無しさん2011/06/05(日) 02:25:55.45
>>27
> コメントで書く説明を、書かなくていいよーな引き数名にすれば済むでしょ。
> そーいう発想で書いてみ?

じゃあお前はsprintfという関数の引数として
何が使えるかを、どうやって引数名に含めるんだ?
35 :仕様書無しさん2011/06/05(日) 02:39:33.61
>>32
先に白状しとくと、俺はC使いではないんで、妄想込みだから脳内保管してくれ。

推測するにsprintfは、
フォーマットとかメッセージを例えば渡すんだろ?
だったら、型抜きで書くなら
sprintf(message, format)
あたりだろ。
messageの型はobjectなのか?各型ごとにオーバーロードしてるのか?その辺りのニュアンスはC使いじゃないんでよーわからん。言語特性にあわせてよろしく定義されてるんだろ。
戻りはvoidあたりか?

で、format辺りは文字列でやってんだっけ?そーすると渋々ドキュメンテーションコメント書く系統の設計になりそうだなこりゃ。
ま、こりゃコメント書かんとダメだな、ちっ、っていう例だと思う。
39 :仕様書無しさん2011/06/05(日) 02:58:44.22
>>35
引数の制約もコード見て調べるんか?
例えばベジェ曲線を計算するメソッドが有ったとして
同一座標が重なってはいけないという制約があるとする。
それをコメントで一言
//頂点が重複する場合は例外が発生する
と書けばいいものを、
反復で変化する値を追い分岐の変化を追って
例外に至る原因となる引数を特定するのか。
42 :仕様書無しさん2011/06/05(日) 03:19:49.38
>>39
その制約を、コードのクライアントが知るべきか?その例外をクライアントが処理すべきかどうか、あたりで変えるかなあ。

つまりバグでしよ?正しいコードじゃおこんねーよ、だったら集約例外でログ吐いとこー方針でAPIには含めない。
業務仕様でしょ?だったらAPIに含める。APIへの含め方は、例外で表現するか、戻りの型?クラス?列挙型?で表現するかは、言語特性次第だな。

実運用上はコードでの表現を第一に考えて「うわーギブアップ!今の俺の実力じゃコ(現実的な時間では)コードで表現出来んわ」となったら、ションボリしながらコメントで言い訳する。で自分にがっかりするw
44 :仕様書無しさん2011/06/05(日) 04:18:28.41
>>42
ゼロ除算と同程度の話なんだけどな。普通そんな座標は入れないし。
メソッドを呼び出す側としては当然知っておくべき制約。
普通ゼロ除算をしちゃいけないと説明されるから値を渡す側はみんな割る数に0を
渡さないよう気をつけるだろそれと同じ。
47 :仕様書無しさん2011/06/05(日) 04:26:24.03
>>44
計算によっては1を渡したら0除算になる場合だってあるだろうさ。
そのことを知らせるにはコメントに書くしか無い。

コード見たって、バグかも知れないと思うだろ。
48 :仕様書無しさん2011/06/05(日) 05:44:10.39
>>47
すまんコメントが必要だとしめるつもりだったのに書き忘れた。
54 :仕様書無しさん2011/06/05(日) 17:11:00.66
>>48
コードとコメントでコメント信じるのはアホだ
コメントはあれだよ、自転車の補助輪みたいなもの。運痴のやつが、親に支えてもらう代わりに、転ばないよーにつけてる感じ?
29 :仕様書無しさん2011/06/05(日) 02:23:28.81
コードを読めば分かるというのは、
逆に言えば、コメントがあればすぐに分かることが
コードを読まないとわならないってことだ。

コードを読む時間が長くなるのなら、
コメントを付けるほうがいい
31 :仕様書無しさん2011/06/05(日) 02:25:45.74
>>29
違うだろ、コードの使用者の感心ごとは、コードの中身じゃない。契約だよ。
中身なんか読まずに済ませたい。
読む必要がないよーに、シグニチャを設計するんだよ。
それが良いコード。
33 :仕様書無しさん2011/06/05(日) 02:33:27.64
double pow(double x, double y)

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


ドキュメント読まないで、引数の名前で推測して
コーディングするやつにまともなコードは書けない。

世間で言われている、「コードの内容を示すコメントを書くな」というのは
i++; // iを一増やす
のようなコメント一文 と コード一文 が完全に対応している場合の話だ。
世間で言われていることを鵜呑みにして、本質をちゃんと捉えてない。
36 :仕様書無しさん2011/06/05(日) 02:52:33.55
>>33
なんか怒らせたっぽいか?すまんな。
だが現場の経験から話してるぞ。
ドキュメンテーションコメント見ながら、コード書く奴がいるのか?を冷静に思い出してみてくれ。
言語そのものといっていい組み込み関数だかAPIだかライブラリの話じゃないぞ?

おまいやおまいの同僚が、昨日や今日書いた、あるいは今さっき修正してコミットしたての、そのコードをだ、
自分があるいはとなりの席の奴が使うとして
ドキュメンテーションコメントを確認して使うのか?それは本当かい?
34 :仕様書無しさん2011/06/05(日) 02:35:07.58
つか、関数にする理由は、
長いコードを読まなくて済むようにするのが目的なので
コードを読めば分かるというのは、
関数そのものを否定しているのと一緒。
40 :仕様書無しさん2011/06/05(日) 03:01:16.90
>>34
x コードを読めばわかる
o シグニチャ見ればわかる

だな。
コードコード言いすぎて一つの語を複数の意味で書きちらしたおれのミス。
複雑さを隠蔽するために書くわけだからコード本体を使用者に読ませるつもりは当然ないよ。
37 :仕様書無しさん2011/06/05(日) 02:53:57.64
開発プロセス次第かもしれんが、スクラッチ書いて、顧客に見せてフィードバックもらって、設計改善して、、
って出荷できる状態を短期に確保しながら動作して使えるコードを書き続ける現場でさ、
コメントとコードとで重複した情報なんか残してたら、修正速度の足かせにしかならんよ。
コメントとコードなんて乖離したらノイズだしな。

だったら、コードだけで伝わるようにしよーぜっ
てなると思うんだが。おもいらの現場は違うのか?
38 :仕様書無しさん2011/06/05(日) 02:54:56.69
コードの内容を素早く把握できるように
コメントを書いておこうぜってなるのが普通
41 :仕様書無しさん2011/06/05(日) 03:01:48.56
「頂点が重複する場合は例外が発生するベジェ曲線を計算する関数」って
意味を表す英語の名前にしておけば良い。
43 :仕様書無しさん2011/06/05(日) 03:21:04.64
そうまでして、コメントをスリムにコードでこそ語ろうぜ!という方針の意図は、DRY原則はいうまでもなく、
本当に気をつけて欲しいこと、コードでは表現出来ない設計背景、判断経緯、確実に留意すべき重大な意図が、どーでもいいコメントたちに埋れてしまわないよーに、だよ。

危険な匂いのするコードには、コメントが書かれてる、それもタップリと。
だから読み落としも防げる。そんな感じ。
46 :仕様書無しさん2011/06/05(日) 04:21:00.15
0で割ったら無限大になる
ライブラリだってあるだろうさ。
50 :仕様書無しさん2011/06/05(日) 12:08:10.42
なんか勘違いしてる人がいるようだが、別にコードで全てを語ろうなんて言ってる人はいなくて
その関数が何をする関数なのかは関数名でほとんど解るようにするのがスマートという話だろ。
51 :仕様書無しさん2011/06/05(日) 12:11:14.09
そして、関数やクラスを作る人の力量は、
それを使う人が気にしなきゃいけないことがどれだけシンプルに収まってるか、に現れるので
コメントをダラダラ書いている時点で何かが間違っていると感じないといけない。

関数の(外向きの)コメントなんて、ヘッダの宣言の横に1行あるかないかで十分だと思う。
55 :仕様書無しさん2011/06/05(日) 17:32:35.08
@throws RedundantCommentException
コメントがコード内容を繰り返すだけで冗長です。命名や設計を改善してコードの意図をシグニチャだけで表現出来るよう成長しましょう。
58 :仕様書無しさん2011/06/05(日) 18:11:03.98
>>55-57

なにwikipediaにのってるサンプルコードに
文句付けてるんだ? 恥ずかしくないのか?
59 :仕様書無しさん2011/06/05(日) 18:21:19.98
@throws Wikipedia厨Exception
大好きなウィキペディアが批判されたと勘違いして感情的になる人間を検知しました。論理的な内容に目を向けるようにしましょう。
@see >>58
56 :仕様書無しさん2011/06/05(日) 17:40:17.24
@throws ExcessiveCommentException
コード総量に占めるコメントが大杉ます。読み手のことを考えることなく、自分が書きたいこと書けることを書き散らすことで、何が重要で何が些細かが伝わりにくい状況です。古い習慣を疑いコメント設計を行いましょう。
57 :仕様書無しさん2011/06/05(日) 17:42:43.81
@throws MisleadCommentException
コードとコメントが乖離しています。コメントを書くことが目的か手段かを混同し考えなしに機械作業を行うと発生する現象です。身の丈にあったコード規約を採用し、コメントがノイズにならないようにすべきです。
63 :仕様書無しさん2011/06/05(日) 20:07:48.23
掲示板 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);
}
65 :仕様書無しさん2011/06/28(火) 01:02:28.79
そもそも、例外が必要なのって楽したいからだよね?面倒くさいチェック処理とか省きたいから。
なんか間違ってるか?

# そんな俺は例外書くことは基本的にない。
90 :仕様書無しさん2011/06/30(木) 01:52:12.04
>>88
いや残念ながら俺は例外処理必須と考えてるわけではない。
初発は>>65だ。

で、まぁ例外処理だって言語に依存しないっていうのはまぁ分かるし、
十分語れるならそれをかたってくれい。
66 :仕様書無しさん2011/06/28(火) 01:27:24.09
例外は用途であって機能ではないけどな。
try-catch以外にも、GetLastErrorやらerrnoといったライブラリ、
割り込み命令で例外を処理してるし。
67 :仕様書無しさん2011/06/28(火) 07:55:40.01
>>66
> GetLastErrorやらerrnoといったライブラリ、
> 割り込み命令で例外を処理してるし。

うん、だからそういうのを一箇所にまとめられる→楽したい ってことなんでしょ?
って思ってさ。
例外処理本来の用途って意味だと、例外が発生してもプログラム三原則に沿って
動き続けるためだろうなーっとは思ってるんだけどさ。
70 :仕様書無しさん2011/06/28(火) 22:22:32.83
>>67
try-catchの事言ってんなら大して、例外処理箇所は変わらんぞ。

例えば、文字列を数値に変えるInteger.valueOfがあるが、
このメソッドは、値が不正なとき例外を出す。
しかし、この例外には何が原因かは情報がない。
原因が何かは、Integer.valueOfに間違った値を渡した
呼び出し元のメソッドしかしらんからな。

だから、基本的にifで戻り値調べて、どの値が間違っています
って書くのと例外処理の箇所は変わらん。

楽になるとすれば、下層のメソッドから上層のメソッドへエラーを
伝えるだけの処理が省けることと、異常のあったループなんかから
抜け出しやすい事。

まぁ、そもそもtry-catchの発端は、C++でエラー情報を戻り値で
伝えられない関数を補助するためだから。
72 :仕様書無しさん2011/06/28(火) 22:36:23.09
>>70
そもそも入力チェックに例外を使っているのが間違い。

例外はその名のとおり例外。
通常の処理の流れでありえない=途中で中断すべき場合に使う物

どの値が間違っているか調べることなんかに
使うべきものじゃない。
73 :仕様書無しさん2011/06/28(火) 22:51:47.32
>>71
原因が何かってのは、幅に文字が入ってるとか、
高さに文字が入ってるとかだぞ解ってるとは思うけど。

>>72
何から入力させてんの?まさかコンソールから値を入力する事を前提にしてるわけじゃないよね。
GUIならさ、普通数値以外を入力できなくさせることができる訳じゃん。ここで数値チェックなんてそもそも
必要ないわけよ。じゃあ他に数値が入っているべき場所に文字列が入ってる状況は?

そうなるとファイルやら通信データになるわけだ。当然データ構造のパースが走る。
パース処理は浅くはない、パース途中で値が無効だと解った時のコールスタックと、
パースが崩れた原因を知っているコールスタックは距離が離れてる。
そういう場合、いちいち例外投げない数値チェックをするのは、処理が2重になる上
コールスタックのif連鎖がある分無駄でしかないんだよ。
74 :仕様書無しさん2011/06/28(火) 22:54:20.31
>>73
例外っての出してもらうもんじゃないよ。


自分がわかるんだろ?
分かるやつが、例外の中にその情報を入れて
投げるもんだ。

その結果「例外には詳細なエラー情報が含まれる」ことになる。

やっぱり例外の使い方分かってないよ。
75 :仕様書無しさん2011/06/28(火) 22:59:02.14
>>74
それはそうだよ。でもそんな話はしてない。
それは、まず例外を受け取ってからの話だ。
77 :仕様書無しさん2011/06/29(水) 06:20:56.28
>>72
中断するべきかどうかっていうのを起点にするならちゃんと判定しろって思うんだけど
どうなんだ?
例外処理って「なんか起きても動き続けるために」使うもんだと解釈してるんだけど。

# 発想としては、ね。そりゃ書き方次第でいろいろ使えるのは分かってる。
78 :仕様書無しさん2011/06/29(水) 07:44:30.67
>>77
だから、例外の処理自体はC以前の時代からあって、
try-catch使おうが、ハンドラー使おうが、戻り値使おうが
例外処理の内容は昔と同じなんだって。
79 :仕様書無しさん2011/06/29(水) 12:38:47.95
>>78
なにについて「だから」って使ってんの?
81 :仕様書無しさん2011/06/29(水) 23:12:26.82
>>77
> 例外処理って「なんか起きても動き続けるために」使うもんだと解釈してるんだけど。

例外処理は、通常の処理とは違う異常事態が起きたことを簡潔な形で伝える物。

伝えるだけ。


伝えた後動き続けるかどうかは
アプリの仕様しだい。
83 :仕様書無しさん2011/06/30(木) 00:20:54.52
>>81
> 例外処理は、通常の処理とは違う異常事態が起きたことを簡潔な形で伝える物。

俺が「動き続ける」といったのはもちろんその「伝えた」以降の話なんだけども、
ぶっちゃけ「なんかよく分かんないことが起きましたので処理を中断して終了」
っていうのは、バッチ的な解釈なんだよね。

オンライン(リアルタイム)の場合は止まってはいけない。できればバッチの場合
でも復帰して続ける。
銀行ATMで「すいませんがなんか想定外のことが起きたんで停止します」って
話になったら業務に支障が出るわけで。

止まっても問題ない場合は止まればいいと思うよ。でもそれは例外処理の本来
の使い方ではないかなぁと思うんだよね。
86 :仕様書無しさん2011/06/30(木) 00:54:13.02
>>83
想定外のことが起こったら、停止するしかない。
想定外のこと以外でも例外発生すると面倒なんだけどな。
68 :仕様書無しさん2011/06/28(火) 21:47:24.94
楽をしたいってのは間違ってるぞ。

楽に例外処理をしたい。

こっちが正解。
69 :仕様書無しさん2011/06/28(火) 22:15:04.97
>>68
fmfm

なるほど、それはそうだね
71 :仕様書無しさん2011/06/28(火) 22:30:18.92
> このメソッドは、値が不正なとき例外を出す。
> しかし、この例外には何が原因かは情報がない。

あるぞ?

例外:
NumberFormatException - 文字列が解析可能な整数型を含まない場合


文字列が解析可能な整数型を含まないという情報がある。
76 :uy ◆hi.ht/Isu2 2011/06/29(水) 05:34:43.51
君たちはちょっとアセンブラレベルから一回考え直したほうがいいです
ポリもーフィズムとか、継承なんかと並んで、例外っつうのも説明されるから
初心者が陥っちゃうところなのかもね

例外なんて、ただの1メソッド扱いでいい。 使わなくたってプログラムは完成すんのに


何をどうしたいのか具体的に言ってみ?
84 :仕様書無しさん2011/06/30(木) 00:38:17.68
まず、throw try catchの概念を捨てて考えたら?
例外機構のない言語で同じ事態に遭遇したらどうするか。
それが基本的な答えだよ。その答えのうち面倒な部分を例外機構が補助してくれる。
例外処理にどんな例外機構を使ってるかは重要じゃない。
85 :仕様書無しさん2011/06/30(木) 00:42:11.79
>>84
その概念を捨てて例外について騙ろうって言うのか?
お前、大丈夫か?
88 :仕様書無しさん2011/06/30(木) 01:24:02.63
>>85
ノイマン型コンピューターには分岐と変数となんやらかんやら・・・。
Cωで書けたプログラムがFORTRANで書けないわけじゃない。
HTML5の技術を使わずjavascriptだけで3Dグラフィックスを
書くこともできない訳じゃない。こんな感じでな。
http://jsbin.com/ubiyay/3/edit#preview

アルゴリズムがチューリング完全ならどの言語にも依存しないのと同じで
例外処理だって言語に依存しないし、十分語れる。
例外情報が必要とかいうなら、staticな共用データ(共用体)に格納すれば
例外機構の無い他の言語でも用意できるし重要じゃない。
87 :仕様書無しさん2011/06/30(木) 01:04:03.92
例外を使おうがそれ以外を使おうが
想定外のことは起きるし、その時にやりたいこともなにも変わらない。

単に例外を使えば簡単に処理がかける。
89 :仕様書無しさん2011/06/30(木) 01:29:31.25
問題は、想定内の事象での例外だな。
まさにスレタイの通りではあるんだが。
92 :仕様書無しさん2011/06/30(木) 09:52:26.36
この板は、相変わらずだな。

例外がCPUとOSに依存しているのをいまだ、まともに理解出来ている人間がいない。
例外はCPUの割り込み処理だと分かっているのか?
その割り込み処理を、個々のプログラムで制御を許しているのは
OSがマルチタスクだと理解できているのか?

技術者のくせに、CPUやOSの仕組みをしらない奴が多すぎ。
99 :仕様書無しさん2011/06/30(木) 22:10:00.40
>>92
それは例外実装のひとつだろ。
実装であって目的じゃないし、本質じゃない。

・例外実装の種類
 ・ハードウェア例外機構
  ・CPU例外
   ・ソフトで検知できない異常をソフトに通知する
   ・基本的に割り込み用途の極一部でしかない
 ・ソフトウェア例外機構
  ・OS例外
   ・アウトプロセスの異常を通知する
  ・ライブラリ例外
   ・結果が得られなかった事を通知する

ハードウェア例外機構 implements 例外機構;
ソフトウェア例外機構 implements 例外機構;

そもそも根底にあるのはタダの例外機構。
機構自体は、何ら例外の主体ではない。
100 :仕様書無しさん2011/06/30(木) 22:36:26.49
>>99
またアホなことを。
ハードウェア例外だろうがソフトウェア例外だろうが
割り込み処理で実行しているのが分からないのか?

根本的に割り込み処理が分かってないから
そんな恥ずかしいことを堂々と書けるんだろうな。

お前の書いた例外処理をだれが処理しているんだ?
CPU以外に誰が処理してくれるんだ?

例外処理は、ノイマン型CPUなのに、なぜ急に処理の順番が変更できるんだ?

頭を使って考えろ。
106 :仕様書無しさん2011/06/30(木) 23:21:27.27
>>100
お前割り込みの意味しらねぇだろ。
割り込みっつうのは、そもそも割り込みコントローラーが能動的に
割り込み信号をCPUに送りつけ、割り込みベクタを実行させ
ポーリングを排除する。
ソフトウェア例外は、ただの分岐。全く割り込み関係ない。
jgeとかjmpとかintやスタブじゃない命令は割り込みとは言わない。
107 :仕様書無しさん2011/06/30(木) 23:31:31.66
>>101-106
何を必死になっているんだ。哀れすぎるぞ。

>>101
具体的には? 言語はなんだ?

>>102
割り込み処理が発生しないと例外処理が出来ないのは納得するんだな。

割り込み処理は、誰が処理をするのか分かるか?
例外から発生した割り込み処理をプログラムが直接受け取るとでも思っているのか?
本当に割り込み処理が分かっていないんだな。

>>104
>処理の順番が変更できないと、分岐もできないだろー。
アホw 分岐はジャンプ命令で書いてあるから分岐するんだろうが、それがノイマン型だ。
トラップ部分全てにジャンプ命令が書かれているのか?
ジャンプ命令が無いのになぜ処理の順番が変わるのか考えろ。

>>105
>たとえば、システムコールがエラーを返して終了したらIOエクセプション、とかいう処理系は
>よくあるし、その実装にわざわざプロセッサ例外を起こしてそれをトラップして、なんて、
>普通はやらない。
疲れるなアホが多すぎて、じゃなぜ例外処理に処理が移動するんだ?
割り込み処理が発生するから例外処理に移動するんだろうが。
お前の書いたプログラムをアセンブラで見てみろよ。
「システムコールがエラー」で例外にジャンプする命令が書かれているか?

>>106
>ソフトウェア例外は、ただの分岐。全く割り込み関係ない。
アホw 自分が書いたプログラムも読めないのか分岐命令が書かれているか?
108 :仕様書無しさん2011/06/30(木) 23:32:54.95
>>106
割り込みについてはそうなんだろうけど、ここで言ってる例外がなにを
さしてるみんなが話してるのかってことを度外視してまで続ける必要が
あるのかって部分で疑問だわ
112 :仕様書無しさん2011/06/30(木) 23:48:43.48
>>107
>アホw 自分が書いたプログラムも読めないのか分岐命令が書かれているか?
書かれてるけど?何が言いたい?
まぁ、その付近にはシステムコールの割り込みが存在する事もあるけど
それはシステムコール用だし関係ない話。そもそもプロセスを跨いだ例外で無い限り
割り込み命令やスタブに出くわす事もない。だいたいWindowsじゃ割り込み命令(int)の
殆どはリングプロテクトの中じゃないと使えねぇしな。基本的に目にするのはスタブの割り込みだらけ。
114 :仕様書無しさん2011/07/01(金) 00:01:33.80
>>107は自分の書いたコードがどうコンパイルされてるか
アセンブラで確認することもしないんだろうなぁ。
115 :仕様書無しさん2011/07/01(金) 00:03:01.87
117 :仕様書無しさん2011/07/01(金) 00:22:04.89
>>112-115
まったくアセンブラも読めないのか、話にならない。
try-catchの間で、catchにジャンプするJxxxのジャンプ命令は書かれていないだろう。
どうやって例外処理が呼び出されているか考えろ。
118 :仕様書無しさん2011/07/01(金) 01:04:05.77
>>115読めよ。読める知識もないのに語ってんのかアホ。
119 :仕様書無しさん2011/07/01(金) 01:14:39.20
>>118
人の書いたソースより自分の書いたプログラムのアセンブラを読めよ。
すぐに分かるだろ。 読めないのか?
120 :仕様書無しさん2011/07/01(金) 01:23:31.80
あのな。try,catch,throwってのは、本当に>>115の呼び出しに置き換えられてるだけなの。解る?
アセンブリ化したコード読んでも、>>115のコードの呼び出しが書いてあるだけ。
わざわざアセンブリで読む意味がない。
121 :仕様書無しさん2011/07/01(金) 01:36:02.87
>>92
半年経っても理解できなかったのか。悲しいな。
http://logsoku.com/thread/hibari.2ch.net/prog/1296098340/285-

時間の無駄だから、みんなスルーして欲しいな。
122 :仕様書無しさん2011/07/01(金) 02:07:40.20
>>120
まったく、なんでアセンブラを読まないのか。読めば解決するだろう。

じゃ、簡単な質問をする。
マルチタスクOSのメモリーは、OSやいろいろなプログラムが使っている。(これは理解できるだろう?)
自分の作ったプログラムでオブジェクトのメソッドを呼び出そうとする。
しかし、そのオブジェクトは不正な値が入っていたとする。(他のOSやプログラムが使っているアドレスを指している)
この時例外が発生するが、他のプログラムやOSの例外処理が動かなくて
自分のプログラムの例外処理が動くのは何故だ?
>あのな。try,catch,throwってのは、本当に>>115の呼び出しに置き換えられてるだけなの。解る?
その理屈だと、どうなる?
123 :仕様書無しさん2011/07/01(金) 02:19:17.20
> しかし、そのオブジェクトは不正な値が入っていたとする。(他のOSやプログラムが使っているアドレスを指している)
> この時例外が発生するが、
例外が発生するかどうかは、OSやCPUのメモリ保護機能によって決まる。
発生するとは限らない。
馬鹿か。

> 他のプログラムやOSの例外処理が動かなくて
OSやCPUのメモリ保護機能によって、OSの例外処理が働く場合もある。
馬鹿か。

> 自分のプログラムの例外処理が動くのは何故だ?
馬鹿か。

> その理屈だと、どうなる?
>>115のアセンブラの動きが答えだろ。
124 :仕様書無しさん2011/07/01(金) 02:21:49.55
>>122
構造化例外の事を言いたいのか?
普通 _set_se_translator()を呼び出し、シグナルを言語仕様のthrow文に変換するコードを渡す。
基本的にOSからシグナルとして伝えられる例外と言語が持つ例外は別物。
暗黙だろうが明示的だろうが何らかのマッピングが必要になる。
まぁ、Javaなんかはシステムレベルの例外は、ランタイムでフックしてthrowに置き換えたり、
VMでリソース監視してVMがthrowしたりするけど、割り込みとは世界が別。
126 :仕様書無しさん2011/07/01(金) 02:53:14.75
>>123
>例外が発生するかどうかは、OSやCPUのメモリ保護機能によって決まる。
>発生するとは限らない。
お前、自分で書いていて矛盾を感じないのか?
例外が発生するときはOSやCPUによって決まる書いているんだぞ。
意味がわからん。
127 :仕様書無しさん2011/07/01(金) 03:10:23.94
>>126
中途半端に抜き出すな。

俺が言っているのは、
> しかし、そのオブジェクトは不正な値が入っていたとする。(他のOSやプログラムが使っているアドレスを指している)
> この時例外が発生するが、

つまり、他のOSやプログラムが使っているアドレスを差したときに例外が発生するかどうかの話をしている。これはOSやCPUによって違う。

たとえばulinuxやMS-DOSとかだと他のプログラムが使っているアドレスを差したとしても例外は発生しない。

なにも矛盾しているところはない。また中途半端に抜き出されたくないから、改行少なく書いてみたよw
134 :仕様書無しさん2011/07/01(金) 09:48:38.85
>>132
誰がごちゃ混ぜ話しているんだ?

まったく、例外はCPU、OSに依存しないと書いたかと思えば
今度はCPU、OSに依存すると書くしわけが分からん。

誰か俺の書いた>>92がどう間違っているのかを、はっきりかいてみろよ。

言っとくが一部の奴が言っている、一部言語に実装されている
擬似例外は、例外機構じゃない、擬似は擬似だ。
正式な例外みたいに言うのは間違っている。
138 :仕様書無しさん2011/07/01(金) 10:37:28.14
>>135,137
まったく自分だけ、かなり的外れ事を言っているのにきずかないのか?
俺以外の奴もこう言っているぞ。(>>127,123)

>OSがマルチタスクだと理解していることがどう例外と関係するんだか。
>たとえばulinuxやMS-DOSとかだと他のプログラムが使っているアドレスを差したとしても例外は発生しない。(>>127)
Windows7とulinuxやMS-DOSの違いは?
あと、>OSやCPUのメモリ保護機能によって、OSの例外処理が働く場合もある。(>>123)
のメモリ保護機能ってどんな時に必要になる?

>> 技術者のくせに、CPUやOSの仕組みをしらない奴が多すぎ。
>それがどう例外と関係あるんだか。
>これはOSやCPUによって違う。(>>127)

お前が割り込むと、話がめちゃくちゃになる。 粘着するな。
143 :仕様書無しさん2011/07/01(金) 13:48:39.22
>>134
> 誰か俺の書いた>>92がどう間違っているのかを、はっきりかいてみろよ。

「例外」の定義が一般的でない俺様定義になっているので、はっきりしません。

はっきりしたいのであれば、「例外」を「CPUの例外」「OSの例外」「言語の例外」あたりに
分類して書き直してください。
153 :仕様書無しさん2011/07/01(金) 22:41:44.55
結局>>92は何が言いたかったんだ?
「お前等バカばっか!!俺天才!!悔しがれよクズがっ」とでも言って
自尊心を満たしたかっただけなのか?まぁ、今のところそうとしか思えない発言だらけだが。

それとも、万が一かもしれんが、もしかしたら、ひたすら割り込みに拘ることによって、
何かが劇的に改善する方法論を知ってるのか。もし、そうならダラダラ押し問答するより
その貴重な方法論をとっとと語ってほしいもんだ。
155 :922011/07/01(金) 22:59:15.09
>>143,144
お前ら当然のように分類を決めているが、だれがその分類で正しいと言ったんだ?
「CPUの例外」「OSの例外」「言語の例外」の具体的な例外は?

この例外をその分類で表してくれ。足りなければ追加してくれ。
・徐算エラー
・配列境界違反
・無効命令
・スタック例外
・一般保護例外

お前らの言っている分類ってなんだ?
158 :仕様書無しさん2011/07/01(金) 23:05:40.73
>>155
・配列境界違反
・スタック例外

程度が知れるなw
161 :仕様書無しさん2011/07/01(金) 23:15:18.85
>>155 そんな事はどうでもいいから、どういうメリットが
ある事を言いたいのか書けよ。
165 :仕様書無しさん2011/07/02(土) 02:15:20.43
>>155
0除算ひとつとってもプロセッサが例外を発生させることもあればソフトウェアが
検知して言語の例外を発生させることもあるわけで、要因に対して分類が1対1で
対応するわけでもない。

IA-32 の Divide Error をどれに分類するか、と具体的に言ってもらえれば、
それは「CPU例外」であるなどと分類を示すことができる。
173 :922011/07/02(土) 08:54:00.52
やっぱりな、結局誰一人分類出来なかったな。
自分達が分類出来ないものを俺に分類して説明しろだと!
知識もない、いい加減な事しか言わない最低な奴らの集まりか。

>>156
IOExceptionは「CPUの例外」「OSの例外」「言語の例外」でどれだ?

>>158
>[割り込みだと両方セグメンテーション違反]
>・配列境界違反
>・スタック例外
>程度が知れるなw
俺には、お前の程度が良く分かるが。
OSレベルの知識しかないんだな。
>両方セグメンテーション違反
馬鹿か?詳細に分類したものを大雑把にいってどうする。
それなら全て例外と分類すればいいだろう。

>>162
なんでお前らが勝手に決めた分類を
俺が出来ないといけないんだ? お前は頭おかしいだろう。

>>165
> 0除算ひとつとってもプロセッサが例外を発生させることもあればソフトウェアが
>検知して言語の例外を発生させることもある
よくそんな嘘を平気で書けるな。
”ソフトウェアが検知して”ってどんな仕組みで感知してるんだ?
具体的に説明してくれ。 まっ逃げると思うが。
174 :仕様書無しさん2011/07/02(土) 09:01:03.51
>>173
> ”ソフトウェアが検知して”ってどんな仕組みで感知してるんだ?

仕組みというほどのこともない。

int f(int a, int b)
{
  if (b == 0)
    throw division_by_zero(a, b);
  return a / b;
}
177 :仕様書無しさん2011/07/02(土) 09:17:06.65
>>173
> やっぱりな、結局誰一人分類出来なかったな。
お前のお題が曖昧すぎるからだろ。 >165 の言うとおり。
179 :仕様書無しさん2011/07/02(土) 11:29:58.30
>>174-176
それは単に例外を発生させているだけ。
それなら、チェックしないで>return a / b;
を実行した場合>return a / b;が検知場所か?

どこで検知して、どう例外処理を実行させているかを聞いているが。
183 :仕様書無しさん2011/07/02(土) 11:45:58.79
>>179
お前の中では「チェックする」と「検知する」が別物で、
「例外を発生させる」ことと「例外処理を実行させる」ことが異なるのか?
微妙すぎてわからんw
184 :仕様書無しさん2011/07/02(土) 12:01:15.01
>>179
> どこで検知して
条件文で

> どう例外処理を実行させているかを聞いているが。
その言語に備わっている仕組みで。

CPUの割り込みも、OSの例外も出てくる幕はない。
185 :922011/07/02(土) 12:04:13.20
まったく、じゃ簡単に書く。
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 :仕様書無しさん2011/07/02(土) 12:13:43.20
>>185
int f(int a, int b)
{
return a / b;
}
もしかして、この場合も事前にゼロチェックしてるとおもってるのか?
190 :仕様書無しさん2011/07/02(土) 12:33:30.09
>>185
b が 0 の場合、前者は C++ の規格に沿って例外処理が実行される。

同じ条件で、後者は未定義動作となるので何がどうなるとも言えない。
プログラムが止まるかもしれないし、 0 が返されるかもしれないし
1 が返されるかもしれないし、前者とまったく同じ動作になるかもしれない。
199 :仕様書無しさん2011/07/02(土) 15:07:36.54
>>155

純粋な機械レベルでの分類
CPUの例外
 算術エラー(SIGFPE)
  ・徐算エラー(VM)
 セグメンテーション違反(SIGSEGV)
  ・配列境界違反(VM)
  ・スタック例外(VM)
  ・一般保護例外(OSまたはVM)
 不正命令(SIGILL)
  ・一般保護例外(OSまたはVM)
  ・無効命令(OSまたはVM)

※CPUから取り出せる例外はこの3種類だけ。
200 :仕様書無しさん2011/07/02(土) 15:09:25.80
>>199
SIGBUS は違うの?
202 :仕様書無しさん2011/07/02(土) 15:13:36.68
>>200
おおそうだね。一般保護例外はと無効命令は(SIGBUS)にも含まれるね。
抜けてたわ。
213 :仕様書無しさん2011/07/02(土) 21:50:44.32
>>210
そこそこはあるよ。いちいち割り算の度にjzとかアセンブリ命令入れてたら非効率だからね。
>>199 に分類されてるものは、インタプリタやVMベースだと言語の例外機構に変換されてんじゃない?
まぁ、C++の場合はハードに依存するマッピングは自分でヤレがセオリーなんだろうけど。
223 :ラプラスの天使 ◆daemontaDA 2011/07/03(日) 12:18:11.54
>>92
それは例外処理の一種あって全てじゃないんだがw

キミらが好きなVBや昔のBASICにも例外処理があってだな、

ネットに転がってる例外処理の解説記事はだな、

例外なく間違いなく間違っているとう事実だ。w
229 :仕様書無しさん2011/07/03(日) 13:02:29.54
>>223
>昔のBASICにも例外処理があって
On Errorのことか? それは例外処理じゃないぞ
例外はfinally機能が大事だ
236 :仕様書無しさん2011/07/03(日) 14:39:42.84
>>94の主張が嘘じゃないなら>>121とは別人なんだろうけど、
121にある過去スレの主張してた内容で見たら、結局は趣味の話。
俺は業務エラーで割り込みなんて気に食わないからよろしくないと思う。って感じの結論になるような。

まぁ、本質()の話題はもういいわな。その部分の理解は多くの場合必須じゃないし。
昨今の職業マのレベルで考えたら、勉強にかかる時間の割りにメリットはあまりないから、
興味がある人が自分で理解すればいいと思うレベルの話で、このスレの目的とは違うでそ。
238 :仕様書無しさん2011/07/03(日) 15:23:26.25
>>229
> On Errorのことか? それは例外処理じゃないぞ
> 例外はfinally機能が大事だ

catchじゃないのか?

finallyはなくてもcatchがあれば
finallyと同じことが実装可能だし。
240 :仕様書無しさん2011/07/03(日) 16:17:11.11
>>229
いや例外処理だぞ。
try catch型例外機構じゃないだけで。
例外機構によって例外処理じゃないと言い始めたら >>92 と同類。
245 :仕様書無しさん2011/07/03(日) 17:24:45.74
>>243
> 俺は>>214よんだから92は間違ってはいないと思っている。

さすがにそれは無い。

LinuxのシグナルやWindowsのSEHなど(OSの例外)がCPUの例外を
プロセスに配信するだけのものがほとんどで関連性が強いのは
認めるが、このスレの主題である言語レベルの例外がそれらに
依存するなどということは無い。

もともと>>92の言う「例外」が「CPUの例外」や「OSの例外」を
指していて「言語の例外」を指していないのなら内容は間違って
いないと言えるかもしれないが、それをこのスレで偉そうに言うこと
自体が間違っている。
246 :仕様書無しさん2011/07/03(日) 17:24:47.91
>>214は"CPUの例外"の扱いについて書いてあるだけ。
何で、「CPU割り込み例外 = 例外」って書いてるやつの肯定になるんだよ。
CPU割り込み例外も例外の一種だから忘れるなというならわかるけど。
てか >>243 = >>92 なんじゃないか?
248 :仕様書無しさん2011/07/03(日) 17:31:03.02
>>229
finally無くてもデストラクタついてりゃ済むじゃん。
デストラクタ無くても.net環境とかRubyとかデストラクタ相当の
ブロックスコープがあるし。
249 :仕様書無しさん2011/07/03(日) 17:33:19.63
>>247 >>214のどのあたりに感化されたの?
上のほうで割り込みベクタとか、スタブとか言って>>92と
応戦してる人はこの内容知ってて話してるようだけど。
250 :仕様書無しさん2011/07/03(日) 17:35:12.73
>>248
はっ?
252 :仕様書無しさん2011/07/03(日) 17:41:02.47
>>248
例外が発生したらオブジェクトを破棄するの?
253 :仕様書無しさん2011/07/03(日) 17:43:33.67
>>252 別に破壊する必要ないけど?
それと、finallyは例外発生の有無に関係ないでしょ?
254 :仕様書無しさん2011/07/03(日) 17:49:46.85
>>249
例外がCPUとOSに依存しているところ。
スタブはOSどまりでしょう。
255 :仕様書無しさん2011/07/03(日) 17:51:34.64
>>254
92はスタブが間違っていると書いているか?
257 :仕様書無しさん2011/07/03(日) 17:53:15.55
>>253
デストラクタはいく動かすの?
258 :仕様書無しさん2011/07/03(日) 17:55:44.35
>>254 やっぱり >>92 か。 >>214は"CPUの例外"で
例外の全てについて書いてる訳じゃないって何度言われ手も >>92 みたいに解らないようだ。
259 :仕様書無しさん2011/07/03(日) 17:56:46.05
>>257
finallyと同じタイミング。
RAIIをはじめとして、オブジェクトの破棄だけに使うもんじゃない。
260 :仕様書無しさん2011/07/03(日) 17:59:44.90
CPUで発生した割込みは >>214の機構を使って各プロセスに通知されるけど
それと言語における例外は別の話だからなぁ。
だから、CPUレベルで0割による割込みが発生して、各プロセスに通知された
としても、それがC++の例外としてcatchできるわけではない。
(catchできる環境もあるだろうけど)

>>92は言語における例外を擬似例外とか言って相手にしたくなさそうだったけど、
そもそもこのスレは言語における例外をどう使うかを議論してきたわけで。
261 :仕様書無しさん2011/07/03(日) 18:00:18.70
>>229 はfinallyを何に使う気なんだろ・・・。
265 :仕様書無しさん2011/07/03(日) 18:33:59.21
>>259
finallyとデストラクタが別の処理だったら?
そもそもそれなら何でfinallyがあるの?
269 :仕様書無しさん2011/07/03(日) 18:41:26.06
>>265 Disposableな一時オブジェクトつくるのが面倒だからだろ。
Javaに限れば、ブロックスコープでの処理の強制実行がないから。
270 :仕様書無しさん2011/07/03(日) 18:41:37.02
>>258
>例外の全てについて書いてる訳じゃない
例えば?
273 :仕様書無しさん2011/07/03(日) 18:44:45.98
>>260
>CPUレベルで0割による割込みが発生して、各プロセスに通知された
>としても、それがC++の例外としてcatchできるわけではない。
出来ない環境ってなに? 具体的に。
275 :仕様書無しさん2011/07/03(日) 18:48:52.01
>>270
FORTRAN時代からException handlingと呼ばれた処理。
損壊データに対する例外処理とかな。
278 :仕様書無しさん2011/07/03(日) 19:47:20.98
>>270
FORTRANの例外はCPUとまったく関係なく動くの?
279 :2782011/07/03(日) 19:48:43.66
間違えた
270→>>275
285 :仕様書無しさん2011/07/03(日) 20:25:08.32
>>273
0 割が C++ の例外として catch できることのほうが稀なわけだが。

できない環境を具体的に挙げろと言われれば、 VC++ で /EHs を
指定すればそうなる。
286 :仕様書無しさん2011/07/03(日) 20:37:05.11
>>285
それで? どうやって実装しているの?
287 :仕様書無しさん2011/07/03(日) 20:48:52.54
>>286
上の方に書いてあるので読み直してください。

つか0除算なんて例外機構で処理するハメになっても何もそのプロセス単体じゃ出来んと思うけど。
本来0除算が発生しないようにプログラムを組むべきだし。
288 :仕様書無しさん2011/07/03(日) 20:50:51.61
>>278
だから例外機構と例外処理は違うと何度言ったら・・・。
289 :仕様書無しさん2011/07/03(日) 20:52:04.64
>>286 >>115 とか。
291 :仕様書無しさん2011/07/03(日) 21:11:02.26
>>287
お前は例外処理でなにをしようと考えてるんだ?
0除算が発生したらやることはない?素人か?
実際に動くアプリを作ったことがないのか?


やるかやらないかは、アプリの仕様次第だが、
0除算が発生したときにやることはたくさんある。

・0除算が発生したことを画面に表示する。
・0除算が発生したことをログに記録する。
・スタックトレースを表示する。
・0除算が発生した処理のみを中断させ、正常なコマンド入力状態戻す。

やることはたくさんあるだろ。
294 :仕様書無しさん2011/07/03(日) 21:23:58.47
>>291
さてあなたの発見したゼロ除算はどこで発生したんでしょうね。

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

tryの中のどこか。

どこで発生したかは、例外オブジェクトが持っている。
例外オブジェクトに聞けば、発生した箇所を
スタックトレースとして取得できる。


常識だと思うんだが、こんなことも知らないの?
296 :仕様書無しさん2011/07/03(日) 21:30:50.20
>>291
大半の例外機構にリトライ機能がないのはなぜか知ってる?
例外が起こり得た範囲の値は全て信用できないからなんだってさ。
RuntimeErrorの類がチェック例外になっていないのはコレがひとつの理由だって。
もうひとつは、プログラマの意図を把握する手段が無いからだって。
298 :仕様書無しさん2011/07/03(日) 21:34:25.56
>>296
> 大半の例外機構にリトライ機能がないのはなぜか知ってる?

ん?

例外機能とリトライ機能は全くの別物だからだよ。

お前が言ってるのは、「関数にリトライ機能がないのはなぜか?」のような
まったく意味不明なことを言っている。

リトライは例外機能とは別に追加するするもの。
どんな箇所にでもリトライ機能は組み込める。
そして組み込むかどうかはアプリの仕様できまる。
299 :仕様書無しさん2011/07/03(日) 21:34:38.55
>>295
0除算が影響するデータはtryブロックから絶対出てこないんだ。へぇ〜。
じゃあその結果はどこで受け取る予定だったんだろうね。

スタックトレースをそのプログラムで解析して、ゼロ除算になった変数を特定しデータを復帰するの?
俺が場所が解るってのはそういう事なんだけど。データ破損についていってるのにスタックトレースとか入門者かよ。
301 :仕様書無しさん2011/07/03(日) 21:37:41.58
>>295
お前、0除算したときにどうするかは
一つに決まると思ってないか?

0除算したら、その値は0として扱うとか考えてるでしょ?
302 :仕様書無しさん2011/07/03(日) 21:37:46.77
>>298
文脈を読め。もしゼロ除算で他に影響が無いならリトライも可能になるはずだろうがって言ってんだろ。
ハゲを初め言語制作者はそれを無理だといってんの。
303 :仕様書無しさん2011/07/03(日) 21:40:09.26
>>300 今例外全般の話をしてないよ。
この1つのレスに答えてるだけ。例外自体は原因を特定できるけどそんな問題じゃない。

> 291 名前:仕様書無しさん [sage]: 2011/07/03(日) 21:11:02.26
> >>287
> お前は例外処理でなにをしようと考えてるんだ?
> 0除算が発生したらやることはない?素人か?
> 実際に動くアプリを作ったことがないのか?
>
>
> やるかやらないかは、アプリの仕様次第だが、
> 0除算が発生したときにやることはたくさんある。
>
> ・0除算が発生したことを画面に表示する。
> ・0除算が発生したことをログに記録する。
> ・スタックトレースを表示する。
> ・0除算が発生した処理のみを中断させ、正常なコマンド入力状態戻す。
>
> やることはたくさんあるだろ。
305 :仕様書無しさん2011/07/03(日) 21:41:47.57
>>297 にも同じ話な。割り込みの話じゃない。>>291のレスに閉じた話。
307 :仕様書無しさん2011/07/03(日) 21:49:46.30
めんどくせぇなぁ。
このコードでゼロ除算が発生した場合、
このクラスのオブジェクトが健全だと言えるのか?
もちろんこのコード自体に問題があるが、
具体的に回避策を上げてみろよ。

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 :仕様書無しさん2011/07/03(日) 21:51:46.15
見づらいんで直した。
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
                  }
         }
}
310 :仕様書無しさん2011/07/03(日) 22:02:21.10
でゼロ除算箇所を確実に特定し復帰する方法はある。

try
{
      y /= x;
}
catch(・・・ゼロ除算キャッチ・・・)
{
      >>303
}
ただし、この場合割り算一回に1個try catchが必要になる。
加えて、そこまで例外箇所を絞り込んでんなら初めからゼロ除算しないように修正しとくのが普通。
311 :仕様書無しさん2011/07/03(日) 22:03:05.07
>>307
バグがあるコードが健全かどうか聞かれても困る。

例外が起きたとき、オブジェクトの状態が異常になることがあるが
それを回復させるのがcatchやfinallyの役割。

catchやfinallyの中で不安定になっていても、
それを抜けるときに回復させていれば問題ない。


回復させるというのは、処理を続行するということはではない。
不安定(不定)である部分をなくすということ。
エラーとして親関数に返すことも回復の一つ。

これぐらいヒントを与えれば、自分で気づけるだろ?
312 :仕様書無しさん2011/07/03(日) 22:04:16.80
>>309 だから割り込みの話はしてないんだっつのアホ。
ゼロ除算があっても >>303の対処ができるとかいたんだろ。
それが無理だっつってんの。それが分かりゃ終わりだ終わり。
割込なんざどうでもいい。
313 :仕様書無しさん2011/07/03(日) 22:04:35.71
>>310
if(x==0) {
  return 'error';
} else {
  y /= x;
}

こうすることに利点を三つ上げろ。
314 :仕様書無しさん2011/07/03(日) 22:05:19.83
>>312
自分で、出来ることを>>310で
証明しているようにしか見えんのだがw
315 :仕様書無しさん2011/07/03(日) 22:06:17.36
>>311
具体的にコードを見せろ。素人じゃないんだろ。経験者なんだろ。さくっとコード出せるだろうが。
まさか、ゼロ除算に対するコード書いたこともないのに空論で語ってるだけのシステム土方か?
パッケージ開発した事があったりすれば解るだろ?
316 :仕様書無しさん2011/07/03(日) 22:07:50.46
>>312
結局さ、お前0除算を例外で処理することを
毛嫌いしているだけじゃね?

どうせ0除算するコードをなくすと言っても
計算する前に0かどうかチェックするだけだろ?

めんどくさいよね。特に式が長くなった時とかさ。

x = a + b / foo() - c;

とかさ。if使ったら面倒になるでしょ。

でお前はifしか使えないから、例外なんか食わず嫌いで使ってないだけ。
317 :仕様書無しさん2011/07/03(日) 22:08:35.88
>>315
まず、お前が先に
ゼロ除算に対する具体的なコードを見せろって
誰かに言われなかった?
318 :仕様書無しさん2011/07/03(日) 22:11:33.09
>>313
最初から、ゼロにならないことを保証したオブジェクトとれば済む話。

int Method(int x,NoZerroObject object)
{
return x /= object.getValue();
}

>>314
>そこまで例外箇所を絞り込んでんなら初めからゼロ除算しないように修正しとくのが普通。
おわかり?
319 :仕様書無しさん2011/07/03(日) 22:12:44.71
>>318
馬鹿だwww

じゃあその変数に0を入れようとしたところで
例外が発生するだけじゃないかw
320 :仕様書無しさん2011/07/03(日) 22:12:49.86
>>317
問題があることを書いただろうが。
なんで問題があるっつってんのに自分で、問題が無いコードを提示すんだよ分裂症か俺は。
321 :仕様書無しさん2011/07/03(日) 22:14:24.49
>>320
お前が示すのは、例外を使わないで
0除算を防ぐコードだよ。
322 :仕様書無しさん2011/07/03(日) 22:15:47.46
>>318
ゼロにならないことを保証した変数を使えば
済む話だな。

>>310の例だと、

y /= NoZerroX ;
323 :仕様書無しさん2011/07/03(日) 22:16:21.62
>>319
ゼロ除算は発生しないよな?
そもそもNoZeroObjectで例外が発せいた場合は、
NoZeroObjectにゼロが入力されたことは明らかだ。
最入力なり何らりさせても他に影響が無い。

問題の発生箇所が初めから特定可能なのと、
>>308のように不特定なのでは全然問題が違うぐらい解るだろ。
324 :仕様書無しさん2011/07/03(日) 22:16:28.96
>>318があまりにも痛すぎるコードな県についてw
325 :仕様書無しさん2011/07/03(日) 22:18:19.98
>>321
例外を使うなとは言っていない。"ゼロ除算例外は対応できない"といってんの?はよコード出せや。

>>322
そうだよ。そのとおり。
326 :仕様書無しさん2011/07/03(日) 22:19:05.23
>>324 が素晴らしいコードを見せてくれと聞いて。
327 :仕様書無しさん2011/07/03(日) 22:20:42.92
>>325はちょっと間違えた。
>>294の場合以外は"ゼロ除算例外は対応できない"だ。
329 :仕様書無しさん2011/07/03(日) 22:24:43.64
>>323
> ゼロ除算は発生しないよな?
つか、本末転倒だろ。

ゼロ除算エラーが発生しない代わりに
ゼロ代入エラーに変っただけじゃん。

割り算するたびに変数の値を、そのNoZeroObjectとやらに
一回代入して0かどうかの実行時チェックをするのか?
毎回毎回。ifでやる面倒さをなにも解決していない。

頭悪いよ。

もしゼロ代入エラーにならないのなら、
xが0になることもないわけで、
そもそもy/=xで例外が発生することもない。
336 :仕様書無しさん2011/07/03(日) 22:45:48.68
>>334
>>303を読んだ上でいってるの?0除算を防げるかどうかがメインのテーマじゃない。
>>303のような対処法無理だし、最初からゼロ除算を防ぐ方法をこうじるしか無いっていう話なんだよ。
337 :仕様書無しさん2011/07/03(日) 22:57:46.71
>>336

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


1.何のために
2.どうやって防ぐか

たった二つだ。
その両方を答えよ。
339 :仕様書無しさん2011/07/03(日) 23:09:34.09
>>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 :仕様書無しさん2011/07/03(日) 23:10:27.16
ずっとレス番間違えてたわ
>>303 は >>291 の事な。 引用してるから解るかもしれないけど。
344 :仕様書無しさん2011/07/03(日) 23:16:59.00
>>339
ならんよ。だってゼロ除算と違って発生場所が圧倒的に少ないんだもん。

try
{
      frameVector.sub(sourceVector);
      return new NoZeroVector( frameVector );
}
catch(・・・禁止されたゼロベクタ・・・)
{
       //図形が成立していないエラー
}

意味論理で考えれば、ゼロ除算の割る値になれる値が0になる箇所なんて
どう考えても最初から成立しない値になる。
345 :仕様書無しさん2011/07/03(日) 23:19:28.56
>>344
言葉が変だった。
>意味論理で考えれば、ゼロ除算の割る値になれる値が0になる箇所なんて

>どう考えても最初から成立しない値になる。
どう考えても最初から成立しない値が発生してるのですぐ解る。
346 :仕様書無しさん2011/07/03(日) 23:20:51.05
>>344
圧倒的に少ないから、ならないというのは
どう考えても論理的ではない。

それにお前初期値の話しかしてないよな?
0になるのは、なにも関数の引数にした時だけじゃない。

長い計算の結果の途中で0になることだってある。
それをどうやって防ぐんだ?

もしかしてすべての変数を0代入不可オブジェクトにするのか。
四則演算し全て使えなくなりそうだな。
なんか俺俺ライブラリ作ってオナニーしているのが目に浮かぶw
347 :仕様書無しさん2011/07/03(日) 23:21:33.27
>>342
>そもそも勘違いは0除算をしたときに
>オブジェクトが健全にならないと勘違いしていることだよ。

じゃ>>308を健全な形に書きなおしてくれ。
コードにすらおこせん御託はいらんから。
348 :仕様書無しさん2011/07/03(日) 23:21:36.67
>>345
最初から成立しない値が入っているのを防ぎたいののなら、

ifつかって変数の中身をチェックすればいいだけだよ。
349 :仕様書無しさん2011/07/03(日) 23:22:44.62
>>347
> じゃ>>308を健全な形に書きなおしてくれ。

それは不可能。ゼロ代入エラーにしても不可能なことを
解決することは不可能。

まずお前が、どんな状態でも完璧に健全になるというコードを書け。
短い例だけではなく、複雑な例でも対応できるやつをだ。
350 :仕様書無しさん2011/07/03(日) 23:24:17.52
>>346
意味論理的にって文字を読んだか?
体積1で高さが0の立方体とか存在すんのか?
机上の空論で語るなよ。具体的な例をあげてみろ。
352 :仕様書無しさん2011/07/03(日) 23:27:13.21
>>349
何行書かせる気だ、一行も書いてないくせに人にかけというな。
しかも、どんな場合でもというなら >>294 に書いた。
354 :仕様書無しさん2011/07/03(日) 23:28:59.95
>>350
だから、お前は初期値の話しかしてないと言うんだよ。

体積を入力してください?
高さを入力してください?

if(高さが==0){エラー}

こういう単純な話しかしてないだろ?
こんなふうに関数の最初で0かどうかチェックできるような例なら簡単だろうさ。
358 :仕様書無しさん2011/07/03(日) 23:32:48.43
>>354
>>355

計算結果の場合は>>344に書いたよな。見たのかよ。
373 :仕様書無しさん2011/07/03(日) 23:57:49.98
>>369 まとめるのはいいが、元々は >>291 は無理って話だったんだけどね。
375 :仕様書無しさん2011/07/04(月) 00:00:23.42
>>373
なにが無理なのか具体的に答えたら?
377 :仕様書無しさん2011/07/04(月) 00:02:48.69
>>373
ん?

0除算が発生したときに、

「0除算が発生しました」とダイアログボックスを表示することは可能だし、
どうようにそれをファイルに保存すればログに記録できるし。

スタックトレースなら普通に出力されるし、
GUIアプリ、ウェブアプリで、0除算が発生しましたとでるが
アプリ自体は終了しないことはたくさんあると思うが?
378 :仕様書無しさん2011/07/04(月) 00:04:36.13
>>375 さんざん書いたよな。

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

とか

>>308
とかさぁ。
381 :仕様書無しさん2011/07/04(月) 00:06:36.12
>>378
それのどこが、

「0除算時にダイアログボックスを表示することが不可能(等)」という
理由になると言うんだ?
387 :仕様書無しさん2011/07/04(月) 00:18:10.75
>>381
んな事いってないだろ。「0除算が発生しました」という無能の極みみたいなメッセージ出すだけならもんだいねぇよ。
それより、健全なオブジェクトと壊れたオブジェクトを判別できない事。なんかい同じ事を書かせんだよ。
問題が発生したオブジェクトが特定できないと、どれが壊れてるか解らないまま処理を継続する事になり、
多少処理する例外処理も失敗するわ、健全なデータも判別できないから、健全なデータも破棄する事になるわ問題が発生するから処理継続は無理と書いてる。
389 :仕様書無しさん2011/07/04(月) 00:40:16.35
>>384
そうかもね。じゃ変更する場合はどうなるんだい?

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

>>386
 >>308
391 :仕様書無しさん2011/07/04(月) 00:55:49.20
>>389

ん? >>308がどうかしたのか?
ロジックによってオブジェクトが壊れるかどうかが決まる
0除算例外にだけ特別なことは何も無い。
そうだよな?
392 :仕様書無しさん2011/07/04(月) 00:57:08.47
>>391
そうだよ。
・壊れたオブジェクト
・無事なオブジェクト
この2種類を判断できない状況で処理を行うな。って話だよ。
393 :仕様書無しさん2011/07/04(月) 00:58:31.28
>>387
例外発生時に発生する副作用が特定できるように、
例外安全性を意識した設計と文書化を行いましょう。

それができてない前提であれば、あなたの言うとおりかもしれません。
でもそれは例外という機能による不可避な問題ではないのです。
394 :仕様書無しさん2011/07/04(月) 00:59:40.99
>>391
あ〜ロジックによってってのはちょっと誤解があるな。
ロジックによって壊れないことが保証されている場合は、そのとおり。
ロジックによって壊れるかもしれない場合は、例外で判断するしか無い。
400 :仕様書無しさん2011/07/04(月) 01:10:54.22
>>398 そうだな。もともと >>291がおかしいって話でボヤけてたが本体がみえてきたな。
402 :仕様書無しさん2011/07/04(月) 01:14:21.27
>>400
おかしいという根拠は
最後まで出てないと思うがw

実際に、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除算が発生しました");
    }
  }
}
405 :仕様書無しさん2011/07/04(月) 01:20:10.33
結局、>>291に難癖つけたやつが
的はずれなこと繰り返してただけじゃねーかw
406 :仕様書無しさん2011/07/04(月) 01:21:20.52
>>402
それを全ての割り算に書くならねぇ・・。っていう話でNoZeroとか出てきたんだけど今更もどるのか、あの話に。
408 :仕様書無しさん2011/07/04(月) 01:23:01.22
>>405
そうだね。全ての割り算に>>291を書くなら的外れだろうね。以下略。
410 :仕様書無しさん2011/07/04(月) 01:27:20.50
>>406
> それを全ての割り算に書くならねぇ・・。
何のために?

423 :仕様書無しさん2011/07/04(月) 02:08:22.06
>>291は正しかったってことか。
結局否定できなかったもんな。
424 :仕様書無しさん2011/07/04(月) 02:16:17.89
>>422 訂正ねぇ。したよ。言い回しが違うだけでいってることは他の人と同じよだったから。
内容は>>404に書いたものと変わってないけど。

>>423
>>291を全ての割り算に書からないなら

・壊れたオブジェクト
・無事なオブジェクト
この2種類を判断できない状況で処理を行うな。

が守れないよねって話を刻々と続けてきたと思うけど。
425 :仕様書無しさん2011/07/04(月) 02:19:34.52
>>424
誤解をまた生みそうなんで訂正。

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

を守るには、>>291の方法だとtry-catchを全ての割り算に書かなきゃならないよね。
426 :仕様書無しさん2011/07/04(月) 02:19:48.43
>>424
だからすべての割り算に書く必要はないんだってばw
例外処理はひとつにまとめられるの。

そして一つにまとめたところで、
ローカル変数に途中の処理結果を入れていれば
どこで例外が起きても、オブジェクトのの完全性は保たれるんだってば。
427 :仕様書無しさん2011/07/04(月) 02:28:15.42
> を守るには、>>291の方法だとtry-catchを全ての割り算に書かなきゃならないよね。

なんで?
428 :仕様書無しさん2011/07/04(月) 02:34:32.55
>>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 :仕様書無しさん2011/07/04(月) 02:40:16.05
いつまで続けてんだよ
>>92はだいぶ以前からスレに沸く見当違いさんだから触るな
初レスとか嘘ついたり、もう来ない宣言のあと当たり前に自演したりとか、相手するだけ無駄だぞ
430 :仕様書無しさん2011/07/04(月) 02:43:09.78
>>428
はぁ・・・。確かというか、例外が発生する可能性があるコードの前、
つまり関数の最初に引数をチェックして、それでOKならそれでいい。

だが引数チェックしたところで、すべての例外が起きなくなるわけじゃない。
むしろゼロ除算例外のように、引数チェックで例外が発生しないことを保証できることなんてまれ。
(つーか、ゼロ除算例外だって計算結果が0になってその値で割れば発生するから引数をチェックしたところで完璧ではない)

だから例外を発生させないようにするという考えは現実的ではなく、コード上のどの箇所で例外が起きても、
問題ない作りにする。これは0除算の限った話ではない。すべての箇所で同じような作りにする。

で、コード上のどこで例外が発生したとしても、問題ない作りにするには、
オブジェクトの状態を変えるコードは処理のなるべく後のほうでやって
途中はローカル変数のみを使ってコードを書く。
これはある程度実戦経験積んだ人にとっては当たり前に書くコードなんだが・・・。

ため息しか出ないよ。こんな初歩中の初歩をしらんやつだったとはな。
431 :仕様書無しさん2011/07/04(月) 02:44:31.23
>>429
ゼロ除算やら割り込みが問題じゃなくなってるんだけどOkey?
433 :仕様書無しさん2011/07/04(月) 02:59:50.36
>>430 こっちの要点は健全なオブジェクトと壊れたオブジェクトを判別し、
安全な状態で処理または、例外処理を継続すること。
まぁ、そもそも保全に対する方向性が違うんだろうね。

俺だって"割り算毎に例外チェック"すんのは馬鹿げてると思う。
でも>>291の方法だとそうは行かない。だから、それを避ける手段を
NoZeroの流れと、メソッドの仕様と例外の区別を利用する流れで提示した。
まぁ、方向性が違うから他の人には納得する点は一切なかったらしい。

10個20個例外が発生する箇所をまとめてキャッチしたらどれが壊れてるのか解からん。
根本的にはゼロ除算は関係ないし、Nullポだろうが、
SQLExceptionだろうが、IOExceptionだろうが同じ話だったんだけどな。

それじゃ消えるよ。めんどうだから。
434 :仕様書無しさん2011/07/04(月) 03:08:59.06
>>433

> でも>>291の方法だとそうは行かない。だから、それを避ける手段を
> NoZeroの流れと、メソッドの仕様と例外の区別を利用する流れで提示した。

それじゃ無理。あくまで関数の最初でチェックできることにしか対応できない。
途中の計算で値が0になったらどうする?
どっちみち処理の途中で例外が発生することになる。

処理の途中で例外が発生することを防ぐことは不可能なのだから、
その場合でもオブジェクトが壊れないようにするには処理の途中でオブジェクトの状態を
変更しないようにローカル変数を使う。普通はそのようにコードを書く。

どうしてもそれが不可能な場合のみ、catchかfinallyで復帰処理を書く。
それがコーディングのセオリーだ。

> 10個20個例外が発生する箇所をまとめてキャッチしたらどれが壊れてるのか解からん。
わかる。例外オブジェクトにどこが壊れているか情報が格納されている。
どうしてもわからないのなら、自分で情報を追加すればいいだけの話。

結局お前は、技術力不足により意味のない俺俺解決方法を思いつき
それを偉そうに語っていただけ。お前の保全に対する方向性が斜め上を向いていただけの話。
実戦経験がないから、変な方法を思いつく。頭が良いのではなく頭が悪い証拠だ。

> それじゃ消えるよ。めんどうだから。
できれば今後一切出てくるな。初心者の相手は面倒だ。
437 :仕様書無しさん2011/07/04(月) 03:17:19.52
>>436
お前の敵はひとりかよw

>>434 も>>433もどっちも実践あるとは思えんから言っただけだ。
両方帰れ。
438 :仕様書無しさん2011/07/04(月) 03:18:54.48
>>437
お前が一番実践なさそうだな。

何一つまともなことを言ってなさそうだからな。
お前の発言はどれかね?w
439 :仕様書無しさん2011/07/04(月) 03:23:56.55
>>438
おれこの口論にゃ参加してないよ。
話を聞き出すならともかく、自分の意見を相手に
押し付けあうなんてバカバカしいじゃん。
社会人なら解るはずだけど?
だから、どっちも実践あるとは思えないって書いたの。
93 :仕様書無しさん2011/06/30(木) 09:57:21.60
お前は口だけでOSを作る上で一番面倒なことは何か理解していないようでしたが?
94 :922011/06/30(木) 10:52:57.93
>>93
俺は初レスだ。
95 :仕様書無しさん2011/06/30(木) 11:06:14.84
だから何。

あんたはトランジスタを、電子の動きを、半導体の作り方を理解して、コンピュータ使ってるのか?
下のレイヤを抽象化するのがエンジニアリングであって、下のレイヤを全部理解してなければ
わからない、と主張するのはバカのすることだぞ。
96 :仕様書無しさん2011/06/30(木) 12:09:47.94
>>95
お前は頭悪いな。自分の文書に違和感は無いのか?

>あんたはトランジスタを、電子の動きを、半導体の作り方を理解して、コンピュータ使ってるのか?
”電子の動き”って、中学で習うだろう、義務教育を受けていれば分かることだが。
それにパッケージになっているLSI(CPU)とトランジスタを比べてどうするだ?(半導体の作り方ってw)

>下のレイヤを抽象化するのがエンジニアリングであって、下のレイヤを全部理解してなければ
>わからない、と主張するのはバカのすることだぞ。
まったく分からん、何が書きたいんだ。”下のレイヤ”・”下のレイヤ”って?OSやハードのことか?
抽象化って、理解出来ていないものを抽象化出来るのか?それはただ単に知らないだけだ。
言葉遊びならとりつくろえても技術者としては駄目だな。

それに、そもそも技術者とは抽象的なものを具象化するものだろう。

別に全部理解しろとは言ってないが例外の話なら例外ぐらいは理解して話せ。
97 :仕様書無しさん2011/06/30(木) 14:57:13.85
フリップフロップ位理解したほうがいかなと、トイレで寝ながら書き込んでいる。
101 :仕様書無しさん2011/06/30(木) 22:40:31.41
ハードウェア例外とソフトウェア例外以外の
例外もあるよ。ただのジャンプで実装された例外。
102 :仕様書無しさん2011/06/30(木) 22:42:30.04
例外処理ってのは、割り込み処理から復帰してから動くコードだよ。
割り込み自体は単に処理の順番を入れ替える地点だけに過ぎない。
104 :仕様書無しさん2011/06/30(木) 22:48:04.04
> 例外処理は、ノイマン型CPUなのに、なぜ急に処理の順番が変更できるんだ?
処理の順番が変更できないと、分岐もできないだろー。
割り込みと例外の区別が付いていないのかなー?
105 :仕様書無しさん2011/06/30(木) 23:02:32.55
例えばゼロ除算とかは、プロセッサの例外をトラップして処理系レベルの例外にするわけだけど、
処理系の発生させる例外はそういうものばかりじゃないからな。
たとえば、システムコールがエラーを返して終了したらIOエクセプション、とかいう処理系は
よくあるし、その実装にわざわざプロセッサ例外を起こしてそれをトラップして、なんて、
普通はやらない。

プロセッサレベルを知ってる俺様無双、って威張りたいだけのバカでしょ。
109 :仕様書無しさん2011/06/30(木) 23:40:13.81
setjmp/jongjmpで実装した例外処理とか知らないんだな、このバカは
111 :仕様書無しさん2011/06/30(木) 23:46:34.33
>>109
それは例外機構じゃないだろう。
113 :仕様書無しさん2011/06/30(木) 23:50:50.48
ソースコード上の話してるだけだから、そういう事いってもわからないんだよ
125 :仕様書無しさん2011/07/01(金) 02:52:47.67
釣れたね。よかったね。
これくらいでもうやめてくれない?つまんないからさ。
128 :仕様書無しさん2011/07/01(金) 03:23:27.07
お前ら誰がどの考えなんだ。
1.例外はOS・CPUに依存する。
2.例外はOS・CPUに依存しない。
3.OS・CPUに依存する例外と、依存しない例外がある。
129 :仕様書無しさん2011/07/01(金) 03:35:07.21
× 1.例外はOS・CPUに依存する。
○ 1.他のプロセスのアドレスを参照することで発生する例外はOS・CPUに依存する。

自分の言った言葉ぐらい
責任をもて
130 :仕様書無しさん2011/07/01(金) 03:49:00.61
>>127
>つまり、他のOSやプログラムが使っているアドレスを差したときに例外が発生するかどうかの話をしている。これはOSやCPUによって違う。
>たとえばulinuxやMS-DOSとかだと他のプログラムが使っているアドレスを差したとしても例外は発生しない。
だから、お前はバカなの? 
ulinuxやMS-DOSでは例外処理が発生しないのはOSによるものだろう。

>>129
お前は何が言いたいんだ? 3と言う事じゃないのか?

お前は本当に意味が分からん、上から読んで整理してからこい。
132 :仕様書無しさん2011/07/01(金) 03:59:38.94
わざとなのか知らないが、アドレス違反などの CPU 例外と、
Windows 構造化例外のような OS の例外と、 C++ はじめ
プログラミング言語の例外とをごっちゃにしたまま話をしたのでは
わけがわからない。
133 :仕様書無しさん2011/07/01(金) 08:42:57.96
ごっちゃまぜ以前に、
すごく狭い自分の知識と視野でしか話すことができないバカが、
半年以上ずっと頑張ってるだけだから。

こんなバカが他で暴れたり仕事したりするのは社会に有害だから、
ここでしっかり構ってやんないとw
135 :仕様書無しさん2011/07/01(金) 09:51:14.16
> OSがマルチタスクだと理解できているのか?

OSがマルチタスクだと理解していることがどう例外と関係するんだか。

> 技術者のくせに、CPUやOSの仕組みをしらない奴が多すぎ。

それがどう例外と関係あるんだか。

例外の仕組みをしらないのはおまえ自身だろ。

> 言っとくが一部の奴が言っている、一部言語に実装されている
> 擬似例外は、例外機構じゃない、擬似は擬似だ。
> 正式な例外みたいに言うのは間違っている。

俺様定義を振り回したってだれもそんなもん知らんわ。
136 :仕様書無しさん2011/07/01(金) 10:04:33.22
>俺様定義を振り回したってだれもそんなもん知らんわ。
一部言語にしか実装されていない擬似例外を
一般的な例外と言う方が”俺様定義”だと思うが。
137 :仕様書無しさん2011/07/01(金) 10:15:56.76
>>136
で、その俺様定義を「そーですね」って言ってあげれば立ち去ってくれるの?
すっごい粘着しそうなんですけど

ここまで粘着するからには
146 :仕様書無しさん2011/07/01(金) 18:17:12.63
>>136
一部OSやCPUにしか実装されていないものを「一般的な例外」と主張するのは俺様定義でしかないなw
139 :仕様書無しさん2011/07/01(金) 10:38:52.93
それが目的ですからw
140 :仕様書無しさん2011/07/01(金) 10:39:31.39
> 自分だけ、かなり的外れ事を言っている

おまえもなんだけどなw
一生きづかないだろうけどw
141 :仕様書無しさん2011/07/01(金) 11:10:08.99
>>139
>それが目的ですからw
嘘つけ、本気で思っていたんだろうが。
それ言い訳、哀れすぎるぞ。

>>140
誤字ぐらいで揚げ足をとるか情けない。お前のも
>おまえもなんだけどなw
おまえ"も"って、自分が「的外れ」だと自覚はあるんだな。
144 :仕様書無しさん2011/07/01(金) 13:59:39.89
「言語の例外」の話でしょ、ここでは
「CPUの例外」「OSの例外」が「言語の例外」に含まれてるから、話がややこしくなってる

「CPUの例外」「OSの例外」を除外した「言語の例外」の話だと自分的には面白くないだけどね
147 :仕様書無しさん2011/07/01(金) 22:19:35.90
>>144
いちいち○○の例外とかうざい。

全部例外でいい。
それで勘違いするやつが馬鹿なのだ。
145 :仕様書無しさん2011/07/01(金) 14:22:34.49
「自分の関わった領域における例外」じゃね?
OSとかCPU(ハード)の例外は別のモノ、つまり「自分の関わらない領域からの例外(≒割り込み)」

後者をどうやるか(回避するか)ってのは確かに面白いね。
人の行う例外入力に対する処理もそれかな? このスレとは若干というかかなりかけ離れる気がするけどさ。

だって、例外を“使う”ってタイトルからすれば命令とか機構をどう使うかって事だし、
CPUとかOSの例外をどうするかっていうと“どう処理するか”ってなるから、例外を“使う”と言う表現はちと違うね。

どっちも意義のある議論項目には違いないと思うけど。
148 :仕様書無しさん2011/07/01(金) 22:20:46.80
「一部OSやCPUにしか実装されていないものを「一般的な例外」と主張するのは俺様定義でしかないなw 」

という定義について意義がある人はいませんか?

いないなら、この定義を一般的なものとしますよ。
152 :仕様書無しさん2011/07/01(金) 22:40:06.84
でも、それでもこのスレを見てしまうのです。僕は病気でしょうか?
156 :仕様書無しさん2011/07/01(金) 23:03:22.60
IOException も知らずにこれだけ大威張りしてきたとはなw
162 :仕様書無しさん2011/07/01(金) 23:19:34.58
OSもCPUも理解してるはずのおまえが、分類できないわけがない。
OSもCPUも理解してるってのが大嘘でした、と大声で宣言しちゃったわけだ(核火暴笑)。
166 :仕様書無しさん2011/07/02(土) 02:29:53.00
「CPU例外」ってのは、バグ潰すのに便利だったんだけど
例外ってのがバグ隠し?みたいな使い方する(される)のがなんとなく
167 :仕様書無しさん2011/07/02(土) 03:04:35.62
なんだ、また例外処理機構wのやつが出たのか。
こんどは32bitだとか8086より先とか言わんのか?
182 :仕様書無しさん2011/07/02(土) 11:43:06.83
割り込みスレでもCPU例外スレでも立てて、そっちでやってくれよ。
187 :仕様書無しさん2011/07/02(土) 12:17:30.78
例外を発生させることができるのはCPUだけ。

という宗教です。
189 :仕様書無しさん2011/07/02(土) 12:25:29.58
割り込みと例外の区別ぐらいつけろよw

0除算とかそういうのは割り込みであって例外ではない。
割り込みを復旧させるときに例外に変換することはある。
だが例外そのものは割り込みではなく
CPUが発生させる物。
191 :仕様書無しさん2011/07/02(土) 12:33:58.07
>>189
CPU の割り込みと例外の区別は CPU ごとに違うので、 CPU を
特定してからじゃないとなんとも言えない。たとえば ARM あたりだと
「割り込み⊂例外」という扱いだったりする。
192 :仕様書無しさん2011/07/02(土) 12:37:12.43
割り込みに性質として、なるべく早く割り込み処理を
終わらせるというものがあるが、
その性質を考えれば、例外とは別物だって分かるだろ。

割り込みは、システム全体から見た他の処理を中断させることになり、
また他の割り込みを遮ることがあるから
なるべく早く復帰しないといけない。

だが例外は違う。ゆっくりとエラー処理をすれば良い。
基本的に該当プロセスで発生した例外は、システム内の
他のプロセスに影響を与えることがない。
194 :仕様書無しさん2011/07/02(土) 13:08:06.93
ここ隔離スレだろw
隔離スレが隔離スレとして機能してるんだから、正常進行じゃないか。

>>192
あー。OSの設計とか次第だけど、割込みサービスルーチンではフラグ立てるか
カウンタをアップするだけで、必要な処理は別に起動したりとかするよね。
193 :仕様書無しさん2011/07/02(土) 12:44:49.48
別に架空の話をしているんじゃなくて
現実に動いているものの話なんだから
動かせば直ぐにわかる問題じゃないのか?
195 :922011/07/02(土) 13:22:02.34
例えば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 :仕様書無しさん2011/07/02(土) 13:24:57.20
>>195
> 例外を発生(throw)させると、WinAPIのRaiseExceptionが呼ばれ
> 割り込み処理(INT 2Eh)が走る。

それ、 VC++ で /EHa を指定したとき限定の話だよね?
http://msdn.microsoft.com/ja-jp/library/1deeycx5.aspx
201 :仕様書無しさん2011/07/02(土) 15:11:49.17
>>195 だからさぁ何が言いたいの?例外は割り込みだけで、ほかは擬似例外と呼べっつう
言葉遊びがしたいだけなの?
203 :仕様書無しさん2011/07/02(土) 15:30:28.39
>>195
INT 2EHはカーネルモードへの移行。所謂スタブと同じ話で
例外とは関係ない。例外に限らずAPIを呼び出しカーネルモードに行く場合は呼び出される。

INT 00は割り込みハンドラを明示的に呼び出す場合に使うもので、除算時にソフトに明示的に
呼ばれる事は無い。除算時はCPUからINT 00に相当する割り込みが発生するだけ。
それがSIGFPE。
204 :922011/07/02(土) 17:05:33.54
>>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レベルの話だ。
198 :仕様書無しさん2011/07/02(土) 13:41:17.79
割り込みはハードウェア的な話(ソフトウェア的に擬似的に発生するものを含める)
システムワイドに発生するものなので、プロセス事の割り込みという考え方はない。

例外は基本的にそのプロセス限定で発生する。
他のプロセスは全く感知されない。

このスレで話しているのは、後者の例外。
プロセス内で完結するもので、それ以外の話は無関係。
205 :仕様書無しさん2011/07/02(土) 17:23:55.91
えーと、このスレでは、

OSが捉えて処理する部分は無関係です。
OSが処理して各プロセスに振り分け
その言語の例外型(JavaならException)に
変換されてからが話の対象です。

INT xxの話で説明するなら、C++の文法でINT xxという
命令はありません。(インラインアセンブラは当然除く)
だからこの部分はC++の話としては対象外です。

また、INT xxが発行されてから、プロセスが直接処理をもらうことはありません。
まずOSが処理します。この部分はC++言語の範囲の処理ではないので
このスレの対象外です。

色々と処理された結果、C++のExceptionとなってからが話の対象です。
207 :922011/07/02(土) 18:21:32.63
>>205-206
わかった、俺も本当は例外が割り込みだから
例外はどうあるべきかを話したかったが
もう俺は書き込まない。

本質を無視して、目先の事だけを話してくれ。
210 :仕様書無しさん2011/07/02(土) 19:56:43.61
>>205
CPUの例外がJavaやC++の例外に変換されるみたいな言い方だけど、
実際はそんなことは稀なんじゃないの?

まったく関係ないことのほうが多いでしょ。
214 :仕様書無しさん2011/07/03(日) 09:02:52.86
216 :仕様書無しさん2011/07/03(日) 11:17:50.69
>>214
読んだらわかったわ、誰が馬鹿かがw
92は”馬の耳に念仏”のことわざを覚えたほうがいいぞw
家畜になにを期待しているんだw
217 :仕様書無しさん2011/07/03(日) 11:38:10.49
>>214
でも、そのLinuxをC++で作るときの例外はどうするの?
241 :仕様書無しさん2011/07/03(日) 16:28:58.32
>>214
それ、210と何か関係あるの?
CPUの例外がLinuxではシグナルに変換されてプロセスに通知される、って話だよね?
WindowsのSEHでもそうだけど、そこから先でさらに言語の例外に変換されることが
あるかどうかって話でしょ210は。
243 :仕様書無しさん2011/07/03(日) 17:04:48.94
>>240
俺もfinallyがないのは例外じゃないと思うな
それならただのエラー処理だろう、名前もOn Errorだし

俺は>>214よんだから92は間違ってはいないと思っている。
92がいなくなるより、240みたいに決め付ける奴にいなくなってほしい。
206 :仕様書無しさん2011/07/02(土) 17:35:49.60
割込みと例外の区別が付いていない奴が騒いでるだけだろ。
割込みの話をしたいのなら、割込みを正しく使えないプログラマ多いね。スレで。
208 :仕様書無しさん2011/07/02(土) 18:26:55.99
「本質」という言葉を使う奴の99%は「俺様の定義する」である件
211 :仕様書無しさん2011/07/02(土) 20:23:10.15
またお前かwなんでこのスレでの例外は言語の機能だと何度言えば…
で、8086より先の話はどーしたのよ。
215 :仕様書無しさん2011/07/03(日) 10:57:31.06
おー…伸びてると思って覗いてみればすごい恥ずかしい奴がいるな…
218 :仕様書無しさん2011/07/03(日) 11:40:19.80
たとえばIOの例外についてだけど
例外を正しく使えないプログラマって、
selectを使いこなせないとかそういうこと?
219 :仕様書無しさん2011/07/03(日) 11:46:59.77
select の exception って、例外つーより OOB 食らった時じゃなかったっけ
socket 関連エラー拾えない実装があったような…
435 :仕様書無しさん2011/07/04(月) 03:12:03.61
>>434
>>219さんお疲れ様。あんたもお帰り。
436 :仕様書無しさん2011/07/04(月) 03:12:47.71
>>435
さっさと消えろよ。自分で言ったんだろ。
222 :仕様書無しさん2011/07/03(日) 12:12:59.29
92は例外がどう実装されてるかという話ばかりで、
例外をどう使うかには興味がないみたいだけど。
224 :仕様書無しさん2011/07/03(日) 12:19:48.51
最後の「本質」が何かじゃんw
それより俺も、痛い奴には氏んでほしいわw じゃま
228 :仕様書無しさん2011/07/03(日) 13:00:42.28
>>224
92は本質じゃなくて、実装について語りたがってたみたいだけどね。
227 :ラプラスの天使 ◆daemontaDA 2011/07/03(日) 12:30:55.83
どーでもいいけど、例外を正しく使えっていう表現が変だろw

例外が起きないようにプログラムを組やがれw
232 :仕様書無しさん2011/07/03(日) 13:47:11.36
>>227
そういう視点でしか見れない人はマには向いてない。
231 :仕様書無しさん2011/07/03(日) 13:46:38.49
にわかなんで214の内容とか理解はしてないけれど
結局92は、実装レベルの視点でみて、何を問題視してたのかがよくわからん。
究極的にどのような問題があるから、実装レベルでの理解が必要だって話なんだろ。

なんつーか、お前らそんなことも知らないのか馬鹿だろ俺は知ってるぞ
っていう事ばっかで、どのレスにも中身がない感。
233 :仕様書無しさん2011/07/03(日) 13:47:29.11
実装こそ本質、と思ってる奴は結構いるよな

下手をすると規格なんて飾りです、とか本気で言い出すw
237 :仕様書無しさん2011/07/03(日) 14:49:14.95
正しく使えない人が多い一番の理由って、
 例外==エラー
という認識しかしてないからじゃないかなって思う。

例外エラーとか、言いたい事はわかるんだけど、
よく考えるとなんか変な気分になる単語みかけることもよくあるし。
244 :仕様書無しさん2011/07/03(日) 17:10:32.07
>>237の言っていることが正解だと思う。
247 :仕様書無しさん2011/07/03(日) 17:30:59.82
そうか?214を読むと他の奴らが言っていることが間違っていたと思えるが。
251 :仕様書無しさん2011/07/03(日) 17:39:51.64
>>247 おかしいな、俺には見えない何かを読んでいるようだ。
256 :仕様書無しさん2011/07/03(日) 17:52:21.72
例外と、例外処理と、例外機構をごっちゃにして例外と呼ぶのをどうにかしてくれんか?
アセンブリをアセンブラでアセンブルするのに。
アセンブリを書くことをアセンブラを書くっていってるぐらい変。ていうか分かりづらい。
そりゃアセンブリの事を聞きかじったヤツがアセンブラ、アセンブラって言ってんのは分かるけど、
アセンブラの設定までしなきゃならん環境でアセンブリをアセンブラと言われちゃなんの事かわからなくなる。

例外についてもおんなじだから。頼むから書き分けてくれ。
ちゃんとExceptionとException handling、Exception mechanismで別れてんだから。
262 :仕様書無しさん2011/07/03(日) 18:13:30.59
finallyはガベージコレクタというか
スコープから抜けだしたときに自動的に
終了処理をできない言語では必須だろうけど、
ほとんどの言語ではできるから、使わないと思うんだが?
263 :仕様書無しさん2011/07/03(日) 18:28:42.93
例外と話ずれるけど、なんでJavaのfinallyってtryが必要なんだろ?
finallyブロックだけありゃいいだろうに。Windowの構造化例外ぱくったからか?
264 :仕様書無しさん2011/07/03(日) 18:32:22.53
>>263
お前はfinallyブロックでなにをするつもりなんだ?
271 :仕様書無しさん2011/07/03(日) 18:42:32.79
>>264
ファイルのcloseとか。
ファイル閉じるのに別にtryブロックは要らんよな。
266 :天使 ◆uL5esZLBSE 2011/07/03(日) 18:34:00.87
これ ; デリミタっていうんだけどさ、これをつけなきゃエラーになるような
そんな言語使ってる奴ってどうみてもゴミだと思うんだけど

もしかして「;」これ打ち忘れてコンパイルエラー出すのが楽しいの?
そうか、二度と話かけんなよ


今日何ゴミの日だっけ?
268 :仕様書無しさん2011/07/03(日) 18:39:29.15
というかfinallyの意味わかってないだろ。

tryブロックに入ったら、そこから出る時に必ず実行されるのがfinallyなんだから、
finallyだけだったら実行すべきタイミングわからんじゃない。
272 :仕様書無しさん2011/07/03(日) 18:44:28.86
>>268
あれ?tryブロック入らなかったら、finally実行されないんだっけ?
274 :仕様書無しさん2011/07/03(日) 18:47:46.98
finallyを使わない人はリソース保護どうしているの?
276 :仕様書無しさん2011/07/03(日) 18:50:04.42
>>274
デストラクタ、disposeとusing。
277 :仕様書無しさん2011/07/03(日) 18:50:39.93
>>274
あとOSとリソース管理ライブラリへの委託か。
280 :仕様書無しさん2011/07/03(日) 19:55:23.27
>>276,277
ファイルクローズやDBクローズもそれでやるのか?
283 :仕様書無しさん2011/07/03(日) 20:13:35.59
>>280
やるよ。やらない理由がないでしょ?
281 :仕様書無しさん2011/07/03(日) 19:55:39.67
だからなんで「まったく」関係なく、が出てくるんだよw
交通事故にクルマの故障がまったく関係ないって言うバカがいるか?
282 :仕様書無しさん2011/07/03(日) 20:00:08.55
>>281
そういう意味じゃなく、CPUの割り込み関係なく例外が動くの?
284 :仕様書無しさん2011/07/03(日) 20:14:20.16
>>282
そもそも、CPUの割り込みと関係ない例外を
話すのがこのスレのテーマだよ。
290 :仕様書無しさん2011/07/03(日) 21:06:50.18
漏れまくりだけど、整理してみた。
とりあえず、下に書いた関係に踏まえてレスしろ。

割り込み = new 割り込み();
入出力制御 = 割り込み;
タイマー等タイミング制御 = 割り込み;
例外機構 = 割り込み;
例外機構 = new OS例外();
例外機構 = new 言語例外();
例外機構 = new 戻り値例外();

例外処理 = new リソース開放();
例外処理 = new バックアップ復帰();
例外処理 = new 初期化による再試行();//Watchdog
例外処理 = new 上位プロセスに通知後終了();
例外処理 = new 例外に対するユーザー操作問い合わせ();

例外 = new 不正メモリ領域へのアクセス();
例外 = new データの破損();
例外 = new 不正データ入力();
例外 = new 入出力失敗();
例外 = new リソース不足();
例外 = new タイムオーバー();
292 :仕様書無しさん2011/07/03(日) 21:11:34.50
>>290
分かりやすく書きなおせ
293 :仕様書無しさん2011/07/03(日) 21:15:16.90
このスレにおける例外というのは、
CPUが発生させたとかハードウェアが発生させたとかは
気にするところではない。

プログラムのコードとして例外と呼ばれるオブジェクトを生成し
それを上位関数に返す行為のことを指す。オブジェクトの生成も
それを上位関数に返すのも、割り込みを必要としない。

一部の例外はハードウェアの状態が例外送信のきっかけに
なっているかもしれないが、そのことを意識してはいけない。

つまり抽象化。

ソフトウェアが割り込み機能を使わずに、
発生された物。それを例外としてこのスレで扱う。
割り込みの話はすれ違い。
297 :仕様書無しさん2011/07/03(日) 21:32:16.92
>294
例外をただの割り込みだと思ってるから
詳細な情報を取得できるってことがわからないんだろうね。

まあ、そういう勘違いしてしまう理由もわからなくはない。
お前が考えている例外はCPUが発生するもの。
つまり言語(プログラムのソースコード)とは関係ない。

例外が言語と関係ない。機械語上で起こることなのだから、
機械語がソースコード上のどこで発生したかを知るわけがない。
このように考えているのだろう。

だから、そういう意味の例外はスレ違いなんだよ。
このスレの例外は、ソースコードのメタ情報を持っている。
ユーザーがいくらでも情報を追加できる仕組みがある。
300 :仕様書無しさん2011/07/03(日) 21:36:40.80
> 例外が起こり得た範囲の値は全て信用できないからなんだってさ。

聞いたこと無いんだが。
信じる信じないも、そこに書いたコードで示されているとおり。

CPUの割り込みの話と勘違いしてるだろ?w
304 :仕様書無しさん2011/07/03(日) 21:41:12.72
あー、こんな話をきたことがあるわ。
アセンブラバリバリ出来る人が
C言語を理解出来ない。

C言語で変数使うと、
このメモリマップはどうなっているのか?と
聞くようなやつがいるって。

アセンブラの知識で気にすることを
C言語でも気にしてしまう。
本来気にする必要がないことを
気にしてしまう。そういう柔軟性のないヤツのことを。

ゼロ除算になった変数を特定することを
気にするのはなぜなんだろうねw
ゼロ除算になったソースコードの行を気にするのならまだ分かるが。(行は取得できる)
309 :仕様書無しさん2011/07/03(日) 22:01:40.25
この馬鹿相手にするのは疲れたから
0除算はこのスレの話題の対象外としていいんじゃないか?

0除算なんて、別にCPUの割り込みを使わなくて実装できるでしょ?

割り算がある箇所をコンパイルしたら、
if 割る数 = 0 then throw 例外 という機械語が生成される
擬似言語の話をしましょうやw
328 :仕様書無しさん2011/07/03(日) 22:23:52.22
誤解されてる気がするが、NoZeroObjectって名前のクラスを作るわけじゃないからな。
得られる値がゼロにならなければクラス名もメンバーも名前はなんでもいい訳だから。
330 :仕様書無しさん2011/07/03(日) 22:25:45.31
>>328
得られる値がゼロにならなければ、例外も発生しませんよ?

例外を使ったコードでも、
問題は解決ですよね。
331 :仕様書無しさん2011/07/03(日) 22:26:07.05
このスレ、Javaでしか考えられないヤツが異様に多い割に、
オブジェクトの完全性とかそういう概念にはかなり疎いのな・・・。
333 :仕様書無しさん2011/07/03(日) 22:29:40.26
>>331
ネットでググッても書いてないようなことはわからないよ(笑)
332 :仕様書無しさん2011/07/03(日) 22:28:38.28
で0除算にならないことをを保証する方法はないんだよね。

変数を使う前に、変数が0でないか
ifでチェックする方法はある。

だが、それは0除算にならないのではなく、
0除算になるコードに到達しないようにしているだけ。

もし到達してしまえば。0除算になる。
335 :仕様書無しさん2011/07/03(日) 22:42:32.15
>>330 そうだよそのとおりだよ。
void Parse(String[] valueBlock)
{
try
{
tihs.polygon.push(new Point( valueBlock[0]., valueBlock[1] ) );
}
catch(・・・エラー・・・)
{
//体積が0になったので入力エラー
}
}
入力時点で0に対処してりゃどこに渡ろうが0になることはない。
まぁ、計算結果0になるのであればそこでの対処はいるが、
0除算エラー例外に比べれば範囲ははるかに特定しやすいし、
他へのの影響もない。

>>332 具体的なコードを書けって。
338 :仕様書無しさん2011/07/03(日) 23:04:25.53
>>337
1. >>303のアホな対応により>>308のようなデータ破壊の連鎖を防ぐため
2. >>335のように意味論理的に0の発生を特定でき、他に影響が波及しないオブジェクトを使用する。
334 :仕様書無しさん2011/07/03(日) 22:41:45.43
0除算エラーがなぜ実行時エラーなのかというと
0除算ってのはコンパイル段階で除去できないからだよ。

たとえばユーザーの入力結果が0になることがある。
0にならなくても、長い計算の末0になることがある。
ユーザーが入力しなくても何らかの統計データを合計して0になることがある。

だから0にならないことを保証する方法はない。

あるとしたら、0にならないようにチェックするコードを書くことだけ。
だがそれは、書けば0にならないが、書かなければ0になるということ。

チェックコードを書くという保証はやっぱり得られないので、
0にならない保証もない。だから0除算を防ぐことを保証する方法はない。
341 :仕様書無しさん2011/07/03(日) 23:11:05.61
1.0除算の結果、その時の変数の値を信用することはできない。

2.ゆえに0除算を防げば、その時の変数の値を信用できる。


※1は間違い。

342 :仕様書無しさん2011/07/03(日) 23:13:43.49
そもそも勘違いは0除算をしたときに
オブジェクトが健全にならないと勘違いしていることだよ。

0除算に限らず、どんな例外が発生したとしても
そのクラスが正しく作られていない限り
オブジェクトは異常状態になりうる。
正しく作られていたなら、0除算が発生しても
オブジェクト自体は健全なまま。

それを踏まえて、0除算例外を0代入例外に
変えたとしても、オブジェクトは異常状態になりうるので
何の問題も解決しとらんのだよ。
343 :仕様書無しさん2011/07/03(日) 23:15:43.12
本質を考えないまま、0除算さえ防げれば
問題解決すると考えているから、
0除算を0代入エラーにすればと訳のワカランのことを言ってるのね。
351 :仕様書無しさん2011/07/03(日) 23:25:56.68
NoZeroなんたらを使ったところで、
try
{
  NoZeroValue ret;
  this.lock = 1;
  ret = frameVector.sub(sourceVector);
  this.lock = 0;
  return ret;
}
catch(・・・禁止されたゼロベクタ・・・)
{
  //図形が成立していないエラー
}

なんてコードを書かれたら、オブジェクトは不健全な状態になるわけだが。
この例だと、lockされたまま処理が終わってしまう。問題はなにも解決してない
353 :仕様書無しさん2011/07/03(日) 23:28:39.81
>>351
入力地点に図形が不正で、座標がオカシイって伝えるに決まってんだろ。
その時点で、このオブジェクト自体は破棄されプログラム上に不正なオブジェクトは存在しなくなるわ。
355 :仕様書無しさん2011/07/03(日) 23:29:45.49
>>353
> 入力地点に図形が不正で、座標がオカシイって伝えるに決まってんだろ。

入力時点で、おかしいかどうか分からない場合だってあるだろ。

やっぱり初期値チェックだけで済む話しかしてないわお前。
357 :仕様書無しさん2011/07/03(日) 23:32:25.63
>>351でNoZeroなんたらを使っていても
オブジェクトが不健全になる例は示した。
話はこれで終わったはずだが。


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


結局、例外が起きたとき健全かどうかは
例外の種類を変更しただけで解決する問題ではなく
その時のロジックで決まるんだよ。
360 :仕様書無しさん2011/07/03(日) 23:36:10.35
>>357
だからそのオブジェクトは破壊されるんだって。
なんで全体で捉えられないの?

try
{
    Example example = new Example();
    example.>>351の処理();
}
catch(略)
{

}
361 :仕様書無しさん2011/07/03(日) 23:38:05.52
>>360
お前、間抜けかw

>>351はお前が言うNoZeroなんたらを使った場合だぞ。

0除算例外を0代入例外にしたところで
壊れるって最初から言ってるだろw
356 :仕様書無しさん2011/07/03(日) 23:31:06.03
つでにゼロ除算エラーが入力地点まで上がっていった場合は、
どの入力した値が不正だったのか全く特定できなくなる。
図形の座標が原因とかそんな情報全くないからな。
359 :仕様書無しさん2011/07/03(日) 23:35:46.04
>>356
じゃあこの例で、どの時点で不正だったか特定してみ。

try
{
  frameVector.1sub(sourceVector);
  frameVector2.sub(sourceVector);
  frameVector3.sub(sourceVector);

  frameVector4 = frameVector3 / frameVector1;
  frameVector5 = frameVector3 / frameVector2;

  frameVector6 = frameVector4 / frameVector5;

  return frameVector6;
}
catch(・・・禁止されたゼロベクタ・・・)
{
//図形が成立していないエラー
}
362 :仕様書無しさん2011/07/03(日) 23:38:58.88
>>359
int i;
try
{
for(i=0;i<frameVector[i].length;++i) frameVector[i].sub(sourceVector);
{
catch(・・・禁止されたゼロベクタ・・・)
{
//図形が成立しんていない i番目の座標が異常
}
363 :仕様書無しさん2011/07/03(日) 23:39:57.26
>>362
とんちかよw


全部一行につなげて書けば、
どこの行かはすぐに分かりますってかwwww
364 :仕様書無しさん2011/07/03(日) 23:42:30.58
>>362
コード書き換えんなよ。
366 :仕様書無しさん2011/07/03(日) 23:51:55.20
>>361
そうですね。但し影響範囲は特定できる。
その情報はNoZeroが出した例外に入っているからね。
引数を書き忘れてたが、この引数自体は破損していないことが確定できる。
もちろんsource自体は、Exampleのオブジェクトに大しては毒だが、
新たなエラーの引き金にはならないことは解る。
例えばエラーメッセージとしてsourceの中身を参照する分には問題ない。

Example example = new Example();
example.>>351の処理(source);

>>363->>364

元がおかしいだろうが。なんで名前の一ベクトルが大量にあるんだよ。
その場合配列しか無いだろ。
仮に名前のついた配列が2本あったらその1個1個でtry-catch書くわ。
380 :仕様書無しさん2011/07/04(月) 00:06:26.08
>>377
スタックトレースをユーザーに見せるの?
あと、sourceの健全性は解らないだろそれじゃ。

sourceってのは>>366で出てくる引数のことな。
383 :仕様書無しさん2011/07/04(月) 00:09:01.04
>>380
366の引数?

それ、例外が発生したら壊れるよ。
壊れるようなコードを書いているからね。

で?
365 :仕様書無しさん2011/07/03(日) 23:45:19.10
コード書き換えて、エラーの箇所を示すための変数を作って
いいなら0除算だって、どこの場所でエラーが起きたか分かるよな。

ここまで頭が悪い頑固爺は初めて見た。

int i;
try
{
for(i=0;i<value[i].length;++i) 100 / value[i]
{
catch(・・・禁止されたゼロベクタ・・・)
{
//i番目の値で0除算エラー
}
368 :仕様書無しさん2011/07/03(日) 23:53:35.97
>>365 それがやりたいんならやればいいんじゃない?
意味合いが解ってて絶対ゼロが来ないと解っててもやってりゃいいんじゃない?
371 :仕様書無しさん2011/07/03(日) 23:56:08.42
>>368
で、計算結果が0にならないということは
どうやって保証するんだ?
367 :仕様書無しさん2011/07/03(日) 23:53:20.75
> その情報はNoZeroが出した例外に入っているからね。

同じ情報が0除算例外にも入っている。

わかった?
370 :仕様書無しさん2011/07/03(日) 23:55:41.57
>>367 具体的にどうぞ。
例えば、exampleが図形で「図形で異常が起きたという例外」が発生すれば、
source側は無事だと解る。じゃゼロ除算の例外でsourceが無事であることをどうやって知るのかな?
372 :仕様書無しさん2011/07/03(日) 23:57:40.71
>>370
お前こそ具体的に答えろよ。

exampleが図形で「図形で異常が起きたという例外」が発生すれば、
source側は無事だとなぜ言い切れる?

376 :仕様書無しさん2011/07/04(月) 00:01:12.35
>>372
「図形が異常で起きたという例外」の仕様がそういう例外だからだ。
IOExceptionがオーバーランが原因で発生することがあるか?
問題の範囲は特定できるんだぞ。

逆にゼロ除算。まぁ別にnullぽでもいいがそっちにそういう仕様はあるか?
379 :仕様書無しさん2011/07/04(月) 00:05:16.02
>>376
例外自体に、オブジェクトの状態を変更しませんと
定義することはできんぞ。

同じ例外を出したとしても、その例外を発生するまでのロジックで
オブジェクトの状態を壊すかどうかが決まるんだからな。

「このメソッドで例外が起きてもオブジェクトの状態を変えません」と書かれていれば、
0除算例外がでたとしても、ほかの例外と同じく、状態を変えないという仕様だ。
369 :仕様書無しさん2011/07/03(日) 23:55:20.33
話をまとめるとだな。

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

いい加減気づけ。0除算かどうはは本質的に全く関係ないと。
382 :仕様書無しさん2011/07/04(月) 00:07:38.97
>>388
> スタックトレースをユーザーに見せるの?

お前は実務経験無いのか?

スタックトレースをユーザーに見せるかどうかは、
アプリの仕様しだいだろ。

ちなみに実際に見せてるアプリは多いぞ。
-vオプションとか-dオプション付けたら表示するものもある。
388 :仕様書無しさん2011/07/04(月) 00:19:22.94
>>382
デバッグ機能はともかく、エラーメッセージ替わりにユーザーに見せるのは最悪だけどな。
384 :仕様書無しさん2011/07/04(月) 00:10:11.51
繰り返すが、例外の種類で
オブジェクトを壊すかどうかなんて決まったりはしない。

例外発生時にオブジェクトを壊すかどうかは、ロジックで決まる。

同じ例外を出したとしても、その例外を発生するまでのロジックで
オブジェクトの状態を壊すかどうかが決まるんだからな。

「このメソッドで例外が起きてもオブジェクトの状態を変えません」と書かれていれば、
0除算例外がでたとしても、ほかの例外と同じく、状態を変えないという仕様だ。
385 :仕様書無しさん2011/07/04(月) 00:12:32.10
やっぱり0除算をCPU例外の0除算と
勘違いしている馬鹿ではないだろうか?


ぜんぜん違う。0除算はほかの例外と全く一緒。
0で割ったときに発生するというだけで
得られる情報も、オブジェクトの状態も
全く変わらない。
386 :仕様書無しさん2011/07/04(月) 00:16:24.23
え? 0除算が発生したら
その時点でオブジェクトが壊れるんじゃないの?
たとえば、全く関係ないプライベート変数の値が変化したり。

って本気で思ってそうw
390 :仕様書無しさん2011/07/04(月) 00:45:44.10
じゃ極論しよう。
・壊れたオブジェクト
・無事なオブジェクト
この2種類を判断できない状況で処理を行うな。以上。
396 :仕様書無しさん2011/07/04(月) 01:01:00.44
>>390
当たり前w
それをお前は例外の種類で区別できると
言っていた大馬鹿者ってだけだ。

ロジックの途中で例外が発生した時、オブジェクトが壊れるかどうかは
ロジックの内容できまるのであって、例外で決まることはない。

たとえ0除算が起こったとしても、それまでの処理の結果を
ローカル変数を使うなどしてオブジェクトを変化させていなければ
オブジェクトが壊れることはない。

また、他のどの例外が発生したとしても、その例外が発生するまでの間で
オブジェクトの状態を変化させていれば、オブジェクトは壊れる。
たとえば、NoZeroObjectに0を代入する前に、オブジェクトの状態を変化させていれば
当然0を代入して例外が発生すると、オブジェクトの状態は壊れている。
395 :仕様書無しさん2011/07/04(月) 01:00:02.46
もう一点、この問題はエラー通知方法に例外を使った場合にのみ発生するものでもありません。
397 :仕様書無しさん2011/07/04(月) 01:03:24.86
> ロジックによって壊れるかもしれない場合は、例外で判断するしか無い。

無理。こういうコードがあったとき、例外の内容を見て
壊れているかどうか判断することは不可能。


void func() {
 try {
  this.lock = true;

  任意の例外

  this.lock = false
 } catch (任意の例外) {
 }
}
404 :仕様書無しさん2011/07/04(月) 01:19:46.49
>>397
例外はランダムじゃないから判断できるだろ。

void func(Source source)
{
try
{
int value = 0;
・・・処理・・・
source.add(value);//add内で例外が発生した場合、sourceは破損。
}
catch(・・・funcが所属するオブジェクトで発生した例外・・・)
{
//・・・funcが所属するオブジェクトが壊れた例外を出す。
}
}
受け取る側は、funcが所属するオブジェクトが壊れた例外かそうでないかで、
sourceがまだ健全であることを判断できる。もちろんaddが行われてないんで
その分結果が違うが。source自体に変化が無いことは解れば十分。
407 :仕様書無しさん2011/07/04(月) 01:22:41.97
>>404
だから判断できるのは例外ではなく
そのロジック限定のことだろ。

ロジックを見ることなく、例外だけで判断できるというのなら
そのロジック隠した。このロジックで例外が発生したとき
壊れないと言い切れる根拠は何だ?

void func(Source source)
{
  try
  {
    ・・・処理の内容は秘密・・・
    例外発生
    ・・・処理の内容は秘密・・・
  }
  catch(・・・funcが所属するオブジェクトで発生した例外・・・)
  {
    //・・・funcが所属するオブジェクトが壊れた例外を出す。
  }
}
409 :仕様書無しさん2011/07/04(月) 01:24:16.57
>>407
 ・ロジックによって壊れないことが保証されている場合は、そのとおり。
 ・ロジックによって壊れるかもしれない場合は、無事かどうかを例外で判断するしか無い。
411 :仕様書無しさん2011/07/04(月) 01:28:29.39
>>409
だから、例外を見ただけでオブジェクトが壊れているかどうかを判断することは
不可能だってばw

どういう理屈で判断できるのか
説明してみ。

どうせこのロジック(メソッド)では壊れないと
書いてあるからが答えだろ。
ほら例外の種類ではない。
413 :仕様書無しさん2011/07/04(月) 01:36:58.34
>>410
>>412

ほい>>399

>>411
ほい>>404

「funcが所属するオブジェクトが壊れた例外」がfuncが所属する
オブジェクトが壊れた時にしか出ないことを仕様として決めてる限り明らかじゃん。
414 :仕様書無しさん2011/07/04(月) 01:38:10.33
>>413
さっきから論破されたリンクばっかり出すなよw
417 :仕様書無しさん2011/07/04(月) 01:44:52.63
>>416
>>404で投げてんじゃん。
419 :仕様書無しさん2011/07/04(月) 01:49:58.07
>>411
そういや、そうだよ。メソッドの仕様に書いてあるからだよ。うんそのとおり。

・ロジックによって壊れるかもしれない場合は、無事かどうかを例外で判断するしか無い
がよく解らないメソッドから出てきても例外だけで判断できると解釈されたんなら誤解だ。

どのオブジェクトが壊れたとき、どの例外が発生するかはメソッドの仕様で決まってる。
だから、どのオブジェクトが壊れたか判断できると書いたほうがただしかったか。
422 :仕様書無しさん2011/07/04(月) 02:07:07.24
>>419
また自分の言葉を訂正したな。

結局お前が言っていることは何一つ
正しくなかったってことじゃねーかw
398 :仕様書無しさん2011/07/04(月) 01:04:46.87
やっと話が集約してきたな。
0除算とは関係ない話だと
最初に行ったとおりさ。
399 :仕様書無しさん2011/07/04(月) 01:08:49.38
まとめるとこうか。

1.
・壊れたオブジェクト
・無事なオブジェクト
この2種類を判断できない状況で処理を行うな。

2.
 ・ロジックによって壊れないことが保証されている場合は、そのとおり。
 ・ロジックによって壊れるかもしれない場合は、無事かどうかを例外で判断するしか無い。
健全なオブジェクトを判断するには、例外の判別が必要。
401 :仕様書無しさん2011/07/04(月) 01:11:34.95
>  ・ロジックによって壊れるかもしれない場合は、無事かどうかを例外で判断するしか無い。
あ、これは訂正すべきだな。

ロジックによって壊れる場合、例外を見たところで
無事かどうか判断できない。
そもそも「ロジックによって壊れる場合」は壊れるに決まってるかw
403 :仕様書無しさん2011/07/04(月) 01:15:30.50
0除算に限らず、任意の例外(0除算含む)が発生したときに
そのことをログに記録するなんてことは
普通に行われているよ。
412 :仕様書無しさん2011/07/04(月) 01:32:00.11
一体なんのためにすべての割り算に例外を書くのか理解出来ない。

例外処理は一箇所にまとめることが可能なのを知らないのだろうか?
そのまとめた例外処理コードから、例外が起きた詳細な情報を
取得できることを知らないのだろうか?

例外をキャッチするだけの人だと、自分で詳しい例外を作って投げるという発想がないのかな?
415 :仕様書無しさん2011/07/04(月) 01:39:41.00
> 「funcが所属するオブジェクトが壊れた例外」がfuncが所属する
> オブジェクトが壊れた時にしか出ないことを仕様として決めてる限り明らかじゃん。

うん、だからロジックによって決まると言うことでしょうがw

もしその例外を俺が作ったロジックから投げたとして
例外を見れば、オブジェクトが壊れないと判断できるか?

実際に可能なことだぞ。俺が作ったロジックから
その例外を投げることは。
416 :仕様書無しさん2011/07/04(月) 01:40:52.44
> 例外をキャッチするだけの人だと、自分で詳しい例外を作って投げるという発想がないのかな?

まさにこれかw

例外をキャッチするだけだから
自分で投げることを想定していない。
420 :仕様書無しさん2011/07/04(月) 01:54:16.95
 俺は、筋の通った間違いの指摘は、認めてるつもりだが、ここぞと同じ事を
言って掛かってくるやつ多いな。単に論破したいだけのヤツが多いんだろうか。
432 :仕様書無しさん2011/07/04(月) 02:48:28.28
ついさっきまで、ゼロ除算だと・・・って
なんかゼロ除算だけに存在する問題が何かがあると
考えていた間抜けがいたけどなw
440 :仕様書無しさん2011/07/04(月) 03:25:42.33
> おれこの口論にゃ参加してないよ。

うんだろうね。

なにも発言せず、偉そうな態度。
よくあるパターンだw
441 :Perl忍者2011/08/01(月) 15:04:01.29
最初から例外でないようにかけばいいじゃんバカだな
本当にバカだな
書く必要ないさっさと消えろ
444 :仕様書無しさん2011/08/04(木) 00:01:13.40
>>441
こういうアホが理解できないんだよな
446 :仕様書無しさん2011/08/05(金) 15:35:07.55
適度な阿呆が独自論展開しはじめると盛り上がるけどねえ
ここまで酷い阿呆だとオモチャにもならないんで
449 :仕様書無しさん2011/10/14(金) 23:15:27.49
いい加減な集約例外とか、統一性のないログ処理とか
もうやだ!
450 :仕様書無しさん2011/10/26(水) 02:30:34.39
例外とかあんま関係ないけど、
条件が間違ってたとか、明らかにコーディングミスで
落ちてる場合って客にどういうメッセージ見せるべきよ?

「予期せぬエラーが発生しました」「システムエラーです」っつうのも、
明らかにうちのミスであって、システム的に未知の異常が発生した
訳じゃないから言い訳がましいように感じる。
452 :仕様書無しさん2011/10/26(水) 03:33:40.91
もういちどやりなおしてください。つづくばあいはれんらくしてください。的な。
453 :仕様書無しさん2011/10/26(水) 07:53:43.15
もう一度やり直しては不味くね?
バグで有る以上、
バグかどうかは判断できてもどこで発生したかはわからんだろ。
事態を深刻にする可能性があるぞ。
454 :仕様書無しさん2011/10/26(水) 09:39:25.86
仕様上予期してないわけだし、システムがエラーなんだからそのままでいいだろ
だいたい、コーディングが悪いのかほんとに未知のエラーなのか判断できるなら対策しろよ
455 :仕様書無しさん2011/10/26(水) 19:00:18.38
>>454
テスト漏れな異常引数とか配列のコレクションのオーバーランとか
すぐバグだと解るけど、対策なんてできるか?
469 :仕様書無しさん2011/10/29(土) 20:32:10.48
>>455
そんなイラつくなよw
ちょっとキチガイなやつだ
そっとしておいてやれ
471 :仕様書無しさん2011/10/30(日) 02:33:19.74
>>469
例外を正しく使え!
456 :uy2011/10/27(木) 01:33:42.33
ひとついわせてもらうと

こんなスレが伸びちゃうのが 日本のレベルの低い由縁


ありえねーだろ・・・・・・・  なんで理解しない
457 :仕様書無しさん2011/10/27(木) 02:57:11.91
kardとか書いちゃうヤツが、ずいぶんよその国に詳しいんだな。
458 :仕様書無しさん2011/10/28(金) 03:12:22.82
触るときは本当に反応してあげる価値がある相手かを考えてから触ろう

技術不足でも、想定できてなかったら想定外のシステムエラー
もみ消したりして続行されるほうが追々困るので、その原因がバグであってもなんであっても
想定してない以上、中断して通知する必要あるよ
459 :仕様書無しさん2011/10/28(金) 21:00:21.08
それは解るんだが問題はどう通知するかなんだよ。
予期せぬエラーと報告する場合で、エラーの発生頻度が低いと
ユーザーが無視可能性があるでしょ。バグだったら取り返しが
つかないことになる前にさっさと報告してもらったほうがいい。
なので、やんわりと「バグだよごめんぬ。さっさとバグレポート送ってね。」的な事を
ユーザーに伝えたいんだ。それをどう伝えるべきかいい方法が思いうかばん。
460 :仕様書無しさん2011/10/28(金) 21:01:37.11
>>459
このバグを報告したら1万円あげますって書けばいい。
461 :仕様書無しさん2011/10/29(土) 00:35:07.80
>>459
例えば給与会計のシステムで

 誰かの勤務時間登録でエラーが出たらガン無視してExcelで手打ちする

みたいなオモシロイことをしやがる会社はある。
ユーザーもアホではないんで、なんとか凌ぐもんだよ。
あまり神経質になりすぎてもこっちが辛いだけでな。

まぁ今のところは本当の意味での例外、例を挙げれば

 ソフトウェア以外の部分で生じたトラブル(LANケーブル断線とか、ODBCとかJDBCの設定ミス)

は例外扱いくらいだ。
DBのコネクション張れないとか、あるはずのJPGファイル読めない(ユーザーがファイルいじってね?)とか、そんなの。
463 :uy2011/10/29(土) 00:59:28.20
>>461
お前みたいなゴミがいるから腐敗していくんだろうな

身の程を知れクソゴミ
465 :仕様書無しさん2011/10/29(土) 01:06:33.96
>>463
どーでもいいから資料出せよ。別スレで出せって言ったろ?

ここで書いてもらっても構わん。
467 :仕様書無しさん2011/10/29(土) 14:12:59.14
一々触るやつも同類まとめてスルーしとけw

>>459
一度納品して、検査がおわっても見つかってない不具合であれば、あとは保守の内容次第だと思う
管理者の日常業務にログチェックを入れてあればそのうち見つかる
定期的にログチェックをやってるなら、エラーが出てたらその時点で対応検討できるからな
一度作ったら放置のような客のとこでは、そういうのは無理だし、そこは割り切れ

まぁ、大きな問題になると困るようなシステムならある程度の管理者がつくから、
ちゃんとログの内容チェックしてくれると思うよ

全体仕様に関われる案件であることが前提だけど、
エラー時のログファイルを日時でファイル名分けた別ファイル出力するようにしておくとかやると
普段あまりログの確認をしないところでも、エラーが見つけやすくなるから、そういう手もある
あとはログチェックから不具合調査依頼を出すための資料収集の手順書を作ってあげたりすると
必要な情報が取りやすくなるので、不具合起きるとマズそうな案件とかでは重宝するかも?

別ファイル化は前後の記録が取れないから、面倒なこともあるので一長一短だけどな
462 :4612011/10/29(土) 00:37:03.64
Excelで手打ちして



Excelで手打ちして上司に『ごめんこの人たちデータ入りませんでしたてへっ☆で済ます

の意味だが。不思議に給与を振り込んでくれる素敵な上司に乾杯。
466 :仕様書無しさん2011/10/29(土) 03:35:05.93
ソースだせ→スルーして他スレ荒らしは典型パターン
逃げるか火病るかで話にならないので誰もソース出せとは言わなくなったぐらい
468 :仕様書無しさん2011/10/29(土) 14:17:08.57
あとはメール通知とかって手もある。大きなシステムとかだとログも膨大だから
エラーや警告が出てたら通知メールを飛ばすって仕組みを用意してやる
もちろん、メールがこけることもあるので、定期的な死活監視用の通知も必要になる
大きなお仕事とかだと、そんなのもあると思う

いまやってる仕事は、業務エラーもシステムエラーも一緒くたに
Exceptionでキャッチしロギングする過去の遺産の糞F/Wの上に乗っかってるから
ユーザーが入力ミスしただけでスタックトレース吐かれて、ログチェックどころじゃねぇけどな!

例外を正しく使えないプログラマが多いね
472 :仕様書無しさん2011/11/06(日) 02:12:22.99
ふぅ。やっぱりこの結論に達するよねw


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


473 :仕様書無しさん2011/11/08(火) 01:51:45.28
運用環境で発生する可能性が常にあり、なんかしらの処理を行う必要があるものなら
どのみち補足するし、別に検査例外で構わんとは思うけどな
ただ、フレームワークの多くのメソッドに throws Exception とかやられるくらいなら、
全部実行時例外にしてくれよって毎度思う
474 :仕様書無しさん2011/11/10(木) 18:48:28.56
Android触っててJavaの割には妙にストレスが少ないと思ったら
ライブラリがほとんど検査例外使ってないんだな
475 :仕様書無しさん2011/11/12(土) 18:00:55.39
>>474
Androidは組み込みだからいつでも落ちますって前提。
中身ほとんどCで、システムのベースはC++だし。
476 :仕様書無しさん2011/11/12(土) 18:24:29.39
JNIでC++アクセスできるなら、最初からC++ベースだけでもアプリ組めるようにしてほしいわ。
軽快に動くメディアプレーヤーつくろうとするとJavaとの通信が邪魔すぎる。
477 :仕様書無しさん2011/12/19(月) 10:01:16.70
趣味マなんだけど例外って重要だと言われる割に
書籍とか探しても触りしか触れられてる物がおおくて正しく使えてるのか不安にはなる

まあ、趣味レベル何でとにかく動けば良いんだけどね、なんか気持ち悪い感じになる
478 :仕様書無しさん2011/12/19(月) 16:01:03.31
例外だけで一冊にまとまってる本あるだろ。
480 :仕様書無しさん2011/12/25(日) 12:53:29.53
>>478
あるの、マジで教えて。
481 :仕様書無しさん2011/12/25(日) 21:33:28.34
>>478
ワロタw
そんなに複雑な仕組みなんてすてちゃえばいいのになw
479 :仕様書無しさん2011/12/19(月) 18:46:25.43
7スレ目でまだテンプレすらないぞ
先に言っておくが俺は作らないぞ
483 :仕様書無しさん2011/12/26(月) 22:54:50.57
だってそんなに複雑ってことはたくさんのバグや不具合を内包してるってことだろ?
485 :仕様書無しさん2011/12/26(月) 23:50:50.31
try-catchについて本一冊書いてんじゃなくて、
errnoを含め、例外情報を受け取った際どうしょりするか、
どういう状況は例外状況と判断するか、例外情報とは
どのような情報をまとめるべきかを書いてんだろ、
Exceptional〜とかな。

例外を try catch throw 構文そのものだと思うな。
486 :仕様書無しさん2011/12/27(火) 00:56:34.60
>>485
だからそんな複雑なもんはいらねっつーのw
10得ナイフを1000得ナイフにして「ほら、使えるでしょ?ね?ね?」っていってるアフォといっしょだな
492 :仕様書無しさん2011/12/27(火) 21:13:10.88
>>486
日本語ワカリマスカ〜?
487 :仕様書無しさん2011/12/27(火) 01:04:59.40
java で throws Exception をみかけるとやる気なくなる
フレームワークの共通処理とか以外で catch(Exception e) を書かざるを得ない状況になるとげんなりする
こういう奴がいる環境だと、ほんと検査例外は邪魔にしかならんな
490 :仕様書無しさん2011/12/27(火) 19:06:12.13
ユーザー通知したり代替処理したりは普通にやるし、考慮されてなければ確認する
仕様書にないから無視とかやってると、使えないマだなっていうレッテルが貼られるわなぁ
491 :仕様書無しさん2011/12/27(火) 19:43:49.09
仕様書にない例外はバグだろ
493 :仕様書無しさん2011/12/27(火) 21:15:16.81
>>491
例外が仕様書にかいてんのもおかしい話だけどな
仕様書に書いてんのは、ErrorとWarningか復帰方法だろ
494 :仕様書無しさん2011/12/27(火) 23:38:16.66
例外は相変わらずよく釣れるなw
>>491←こーゆーなんもわからない奴ってなんで減らないの?
495 :仕様書無しさん2011/12/28(水) 11:09:53.00
>>494
たった1行で相手が「なんもわからない奴」って断言できる人間がいるからじゃないかな。
お前にとっては、いつまでも「なんもわからんない奴」だらけだろうよ。1行で判断するんだから
497 :仕様書無しさん2011/12/28(水) 17:59:51.67
匿名掲示板なんだから1レスしか書き込まれなかったら
そこで判断するしか無いだろうに
匿名の場において個人は、ひと続きのレスという
一時的な存在にしか見えないんだから
501 :仕様書無しさん2012/01/04(水) 06:19:15.97
>>497
悪いこた言わないから、心療内科池
499 :仕様書無しさん2011/12/31(土) 00:07:28.48
エラーはすべて例外にする例外原理主義
慣れると正常系と異常系の処理がきっちり分けられて便利
500 :仕様書無しさん2012/01/03(火) 15:59:09.29
例外は東京電力の非常用発電機みたいなもの
想定外です
502 :仕様書無しさん2012/01/05(木) 21:09:00.86
IDやIPの類も無しに違う文体、違う内容を書きこまれて
同一人物だと断定できるんだ(´・∀・`)ヘーすごいね
504 :仕様書無しさん2012/01/07(土) 01:48:46.85
>>502
おまえは一体何を言ってるんだ?
誰が「同一人物だと断定できる」とか、できないとか言ってるんだよ。
脳みそおかしいだろ
506 :仕様書無しさん2012/01/07(土) 10:00:14.89
まぁ、「心療内科池行け」としか言ってないわな
それが何を意味するか解釈すんのは人それぞれだけど
507 :仕様書無しさん2012/01/07(土) 11:42:01.70
昔からこのスレは頭の弱い子沸いてるんだから、いちいち構うなって
516 :仕様書無しさん2012/04/17(火) 23:59:23.72
使えないっていうか、理解してないし理解しようともしないし理解する能力もないっていう、そういうのが多い
518 :仕様書無しさん2012/04/18(水) 10:17:01.96
いやそれは自分に出来ないことを他人に押し付けるのは誰もいい顔しないだろう
519 :仕様書無しさん2012/04/18(水) 20:32:22.30
押し付けるとか、そういう使い方をするもんじゃないしなw
処理からするとどう対応するかが決まってない問題とかは例外
処理を呼ぶ側がどう処理するかを決めれるようにするものだしな

同じ対応する異常系を集約しやすいからちゃんと作ってあれば超便利
でも例外理解できない奴は例外==悪い事、程度の認識しかなくて、発生するとふぁびょる
520 :仕様書無しさん2012/04/18(水) 20:40:26.10
そんなに複雑な理由じゃなく、単に正しい結果を返せないなら例外だろ。
521 :仕様書無しさん2012/04/20(金) 00:46:07.18
職場で例外処理使用禁止になりそうです。
あるできるプログラマーが例外を理解してなくて、
例外の使い方を間違えて、例外が遅くてわかりにくい機能だということにされた。
Googleのコーディングルールに例外を使わないよううたわれていることが致命傷だった。
522 :仕様書無しさん2012/04/20(金) 07:01:37.33
>あるできるプログラマーが例外を理解してなくて
できねぇだろそいつ。つかAPIが投げてくる例外どーすんのさ。全部呼び元で握りつぶすのか?
523 :仕様書無しさん2012/04/20(金) 10:32:25.50
そんなんが「できるプログラマー」って時点で終わってるので、
とっとと逃げて、トドメのために魚雷ぶちこんでやるのが男の情け、という気がする。
524 :仕様書無しさん2012/04/20(金) 14:42:46.35
運用時に例外投げてくれる可能性があるからAPIのはなんとか握り潰して
自分等では使わない方針は俺は賛成

そもそもメソッドの結果なんて成功か失敗か(bool型)で足りるのに
わざわざ返す例外を1つ1つ全部呼び元で対処しなくちゃいけない仕様はおかしい
100箇所でメソッド呼んだら100箇所で同じ対処せなあかんのかと・・・?

使う側がマニュアルみて例外の対処1つ1つ・・・ってその発行した例外が出たときに
何をしなきゃいけないのか知ってるのは間違いなく例外なげた奴のほうだろ?

だったらてめぇのメソッド内でやれよ
外側からできる仕様にしてやっからよ
529 :仕様書無しさん2012/04/21(土) 07:33:22.09
>>524
エラーありか、無しかだけが欲しいなら
catch(...){}で捕まえても構わんのだぞ
525 :仕様書無しさん2012/04/20(金) 19:48:02.21
その場で復旧できてそこまで共通化する必要があるなら
ラッパーなりヘルパーなり作ればいいだけだろ
なにプログラム初心者でもわかってくれるレベルの事に長文書いてんのw
526 :5212012/04/21(土) 07:21:46.87
書き忘れましたが言語はC++なのでAPIが例外を投げてくることはありません。
そのできるプログラマーはちゃんと実力のある人です。ちなみに外人です。
Googleのコーディングルールでも例外禁止だし、
Effective C++の著者Scott Mayerも例外に否定的だし、著名なアメリカ人にも否定派は多いようなので、
例外はちょっとまだ受け入れられていない感じがします。
パフォーマンスの問題とか、挙動を予測できない問題とかは、言いがかりに近い誤解なんですけどねー。
いくら説明しても無駄なので、実績のある著名人の論文でもいくつか出さないと通らないっぽいです。
527 :5212012/04/21(土) 07:26:02.60
例外発生時にいちいちキャッチする必要はないでしょう。
例えばシミュレーションプログラムを実行中に0除算が起きた時、適当な値に直して継続させることはマレで、
その計算の一部分または全体をキャンセルしてしまうのが普通では。
つまりcatchはthrowに比べて大幅に少ないはず。
そこのパラダイムシフトに気づかないと例外の利点は理解できないと思う。
528 :仕様書無しさん2012/04/21(土) 07:29:52.89
キャンセルするのに例外使うんだろ
で、失敗した時の通知やログ出力にcatchを使う
return のチェーンを置き換えただけ
530 :仕様書無しさん2012/04/21(土) 08:47:31.26
まぁたしかにC++ならあんまり例外使いたくない気も。解放し忘れとかやっちゃいそうだし。例外使わなくてもやっちゃうんだけどさw
531 :仕様書無しさん2012/04/21(土) 09:42:53.05
クラスきちんと設計できてるなら例外使わないとむしろめんどいケースが多いな
何が楽しくてチェックして結果リターンして、みたいなアホなこと繰り替えさにゃならんのか、ってなるな
それを回避しようと思ったら、例外を使わない前提で
階層構造にはなるべくならないようなアホ設計をやらにゃならんくなる
そして1メソッドの行数がえらいことになるなどが多数出てくる
548 :仕様書無しさん2012/04/22(日) 18:44:00.15
>>531
try-catch無い場合は余計階層が増えるんじゃないか?
でないとgoto使わなきゃならんはめになる
532 :仕様書無しさん2012/04/21(土) 09:47:58.39
ああそうかそういうことか
1メソッドにずらーーーーーと書くようなコーディングルール()な環境だと
例外いらないって考えが生まれるのは理解できなくもないな
533 :仕様書無しさん2012/04/21(土) 11:43:54.22
> 書き忘れましたが言語はC++なのでAPIが例外を投げてくることはありません。

間違いです。お前素人ですか?

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

間違いです。お前素人ですか?


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

間違いです。お前素人ですか?


534 :仕様書無しさん2012/04/21(土) 11:44:43.06
> 書き忘れましたが言語はC++なのでAPIが例外を投げてくることはありません。

だっせwwww

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

だっせwwww


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

だっせwwww
535 :仕様書無しさん2012/04/21(土) 16:54:52.27
環境を何も書いてないから例外を投げないAPIなのかも知れんが、どんなんだろ。
あとはC++といいつつCのライブラリしか使わんとか。んなわきゃないか。
539 :仕様書無しさん2012/04/21(土) 23:19:06.87
例外は基本システムエラーだけど
catchして適切に処理を施して続行する時点で業務フローに組み込まれる
540 :仕様書無しさん2012/04/21(土) 23:36:32.97
システムエラーじゃなくて
実行時エラー。

実行時にならないとわからないものが例外。
541 :仕様書無しさん2012/04/22(日) 00:39:44.40
bad_alloc 受け取ったからって、アプリ側で何が出来るんだろ。
どうせプロセスごと落ちるなら後始末もへったくれもないし。
543 :仕様書無しさん2012/04/22(日) 01:06:39.56
その外人さんってリーナストパーズみたいな
C++はゲロ。低レベル開発はCこそ至上ってタイプのひとじゃないの?
例外投げると、オーバーフローとかthrowされない狭義の意味での
例外処理サボるから糞だと思ってるんじゃね。
多分暗黙の処理とかも大嫌いなんだろう。

>>541
キャッシュ用メモリの解放
応用として不要になってもbad_allocが発生するまでdeleteせず放置とか
546 :仕様書無しさん2012/04/22(日) 05:13:36.09
>>543
個人的にだけど、C言語に極端に意識が慣れてしまうと、gcとか何かを完全に任せちゃってしまう
ようなものって逆に不安でさー。
便利だって意識より、俺の知らんところでこいつ一体なにやってんだろって気になっちゃう。
だから、頭では分かっていても使いたがらないというか。

例外も、自分でちゃんと処理書いてきっちりなにが起き得るのかを分かってて書いてしまいたい
という意識の方が強くて。普通の人ならいちいち書かないで例外任せにするようなチェックも
かいちゃうなぁ。まぁ、newとかで例外起きるとかってのは例外で拾うしかしゃーないけども。
542 :仕様書無しさん2012/04/22(日) 00:42:02.74
> bad_alloc 受け取ったからって、アプリ側で何が出来るんだろ。

エラーログにどこでエラーが発生したか書き込むとか。
544 :仕様書無しさん2012/04/22(日) 01:41:01.71
もうなんにもできないくらい追い詰められてるのと
一仕事しようと大きくメモリ確保しようとしたときじゃ
違うだろ
545 :仕様書無しさん2012/04/22(日) 02:25:10.99
だよね。
例外だと一律に何も出来ないと
決めてはいけない。
547 :仕様書無しさん2012/04/22(日) 05:16:33.31
あ、ごめん。
最後の一文は「catchで拾うかスルーしろ」、のミス。
549 :仕様書無しさん2012/04/25(水) 17:43:08.46
Javaはウンコ。
プログラマーと呼ぶべきかどうかも微妙。
551 :仕様書無しさん2012/04/25(水) 21:23:28.03
>>549
全面的に同意
552 :仕様書無しさん2012/04/25(水) 21:29:15.30
>>551
釣れましたwwwww
553 :仕様書無しさん2012/04/25(水) 21:30:57.73
>>549
すこぶる同意
555 :仕様書無しさん2012/04/25(水) 21:43:49.89
>>549
同士
557 :仕様書無しさん2012/04/25(水) 22:03:31.43
>>549
禿同
558 :仕様書無しさん2012/04/25(水) 22:07:27.07
>>549
マンセー
559 :5492012/04/25(水) 22:08:56.27
>>558
お前だけは許さない。ぜったいにだ!
561 :仕様書無しさん2012/04/25(水) 22:20:34.56
>>549
このレスを見たおかげで
もう医者から治らないといわれ絶望していた
腰痛がなおりました
566 :仕様書無しさん2012/04/26(木) 00:34:08.27
>>549
感動したっ
550 :仕様書無しさん2012/04/25(水) 21:14:56.60
ほらほら、釣り釣り
556 :仕様書無しさん2012/04/25(水) 22:03:22.31
>>550-555
お前らプロの釣りキラーだなw
554 :仕様書無しさん2012/04/25(水) 21:41:10.97
こんな下らないことで
釣りとかレスの応酬とかするなよw
562 :仕様書無しさん2012/04/25(水) 23:46:25.77
Javaもjavaだけど。
今のIT業界がおかしくなったのはJavaのせいじゃないのか?
プログラマーを猿にしたのはJavaのせいだよ。
正直、ホスト出身でもなれるくらいで、現場にいたんだよ。プログラマーも舐められたもんだと思った。

俺はまだC/C++,asmで食べてるけど、この分野は基礎がしっかりしてないと無理。
568 :仕様書無しさん2012/04/26(木) 09:12:59.52
あいちーは一気に広まって土方と同じ状態になった

例外すら理解できないような底辺マが多すぎるのは、
技術がないのに技術者枠で身売りされてるのが原因
人売ってるだけで何もしないで中間マージン取ろうとしてる企業が多すぎる
発注元がもっとスキルを持って技術を知り、直接技術者を囲う体制が不足してる

どの道、今のスタンスのままじゃ、競争力がない日本は世界的に置いてかれるのが目に見えてる
悲しい
569 :仕様書無しさん2012/04/26(木) 10:22:10.16
士農工商からどう変転したものか、
「工」を社会の最低辺層と考える風潮が死なない限り日本の復活は無理。
そしてそれは、死ななきゃ治らない病気っぽい。

よって希望はない。とか思ってる。俺の死ぬまでは保ってほしいものだが。
571 :仕様書無しさん2012/04/26(木) 22:44:44.70
>>569
一応言っておくがな、

士農工商っていうのは、偉い順じゃねーぞ。
570 :仕様書無しさん2012/04/26(木) 19:07:49.33
産業革命の労働者と同じ
過酷な環境と長時間労働と搾取

おまえらが教科書に載るんやで
むねあつ
576 :uy2012/04/30(月) 19:10:05.11
いやいやほんと
半年くらいここ見に来なかったけど、
まだ例外とかやってたんだね

オブジェクト指向に関しては、否を唱えるスレも2chに出てきたけど
例外は未だに
577 :仕様書無しさん2012/04/30(月) 19:36:07.88
オブジェクト指向に関して否を唱えるスレを
見てきて分かったが、

オブジェクト指向がやっぱり現在一番
使える技術だよ。

例外もかな。

否を唱えている奴らが
こてんぱんにされてるのを見るとね。
578 :uy2012/05/02(水) 01:59:26.26
OOに否を唱えてる奴らは
そのOOではない設計手法に名前がついてないんだから議論じゃ勝てないよ

っつーか君、2chのこんなそこら中が底辺PGしかいないような場所で
議論で勝った程度でその決め付けはどうかと思うがね

君の世代では例外も使い続けるだろう
たくさん書いててくれ
それが次の世代の良い失敗例の良い模範となる

人は一度間違えた道を進みはじめても、そこを行き止まりまで行かないと気がすまない生き物だからね
行き止まりまでさっさと行ってくれよ
579 :uy2012/05/02(水) 02:03:49.54
OOは現在一番使える技術で間違いはない
万人に使える技術を採用しなければ、会社はアプリケーションを開発できない
俺が言っているのは、「OOの次」を見始めた奴がちらほら2chでも出てきたという事だ
580 :仕様書無しさん2012/05/02(水) 02:25:02.16
OOの次なんてものはない。

OOと共に。両方合わさっていく。
581 :仕様書無しさん2012/05/02(水) 02:28:37.84
OOは使い方によってはそこそこ使えるぞ。
前もお前に言ったが、間違えた抽象化や命名が混乱させてるから糞なだけで、最強ではないけど、正しく使えばそこそこだよ。
ただし、糞コード書くやつが多い。
糞コードは一目で糞コードだと解る言語の方が、混乱は少なく済む。
考えられてるのかとおもっていろいろ調べて観察した結果クソコードだったら書いたやつ頃したくなる。
582 :仕様書無しさん2012/05/02(水) 07:43:58.54
そもそもOOが構造化の延長だからね。

クラスやカプセル化、インターフェイス、隠蔽なんかは構造化と大きく被っている。

OO独自なのはオブジェクト間の関連に関する技術。
UMLやデザインパターンなんかだね。
継承や多態なんかもどちらかといえば構造化より関連に属する部分だろう。

例外は構造化プログラミングの範疇にあるものだと思う。

そういうわけでOOの次がくると言われて20年以上経つけど、それらしいものは未だ出てきてないので、俺が生きている限りは次はなさそうな気がする。
エージェント指向もOOの次だなんておこがましいものだったし。
583 :仕様書無しさん2012/05/02(水) 08:43:34.42
あんたが単に「分割して統治せよ」という大原則をわかってないだけ
585 :仕様書無しさん2012/05/02(水) 09:14:35.99
>>583の間違い。
584 :仕様書無しさん2012/05/02(水) 09:14:02.34
>>587が一体何に対して戦っているのか見えない。
586 :uy2012/05/02(水) 13:49:59.01
ひとつ分かってるのは再帰で書くと
ループで書くよりも記述量が少なくなったり、
変数が消せるって事

それを常に書いていけない理由は、人がバカだからとしか言えない
いずれ遠い未来使いこなせる奴が出てくると思う
そのときにOOはプギャーwwwといわれる
588 :仕様書無しさん2012/05/02(水) 14:53:49.91
糞スレを立てまくったアホがいたからな。
糞スレ消化要員としてせいぜい煽っておこう。
589 :仕様書無しさん2012/05/02(水) 15:43:58.15
えー、再帰なんか普通に使うだろ。
どんだけスキルの低い職場なんだよ。
591 :uy2012/05/02(水) 19:53:07.81
>>589
じゃ、今日からOO捨てて再帰で書いてみっつって出来るんですか?

お前の考えてる部分の再帰の話じゃないよ
590 :仕様書無しさん2012/05/02(水) 15:48:29.88
鉄器時代のFortranで育ったジジイが幅を利かせてた時代には結構あったのよ。
(マネージャーが理解できないから)再帰禁止とかそういうルールが。
593 :仕様書無しさん2012/05/02(水) 22:19:35.91
なんで例外のスレでOO談義なんだ
Cに置ける構造化例外機構、C++の何でも投げられる例外機構、
Scheamの継続による例外機構、AdaなどPascal系の整数を投げる例外機構。
大半の例外機構じゃOOなんて関係ないだろ。
595 :仕様書無しさん2012/05/02(水) 23:12:16.74
>>593
このアホコテは昔から
「例外≒OO=悪」
という超シンプルな間違った知識しか持ち合わせていない
そこから全く成長していないから相手するだけ無駄
598 :uy2012/05/02(水) 23:49:09.04
>>595
例外が悪とかいってないよ
オブジェクト指向(笑)やっていく上では例外に頼るしかないよね
それはどういうことかというと、

そもそもオブジェクト指向が斜めに立てられた建物であって
オブジェクト指向で大きなもの作っていくとどうしても
それを支える添え木として例外が必要になってる事に気づこうか

そもそもw newで例外が発生するからプログラマがそこにコードかくとかwwwwwww
・・・OSか言語設計見直せよって話じゃん

OSや言語が斜めに立てられてるから、プログラマは例外で添え木をするしかなくなっているんだよね可愛そうにね


俺もRubyで例外は使うよ
でも静的言語で使うような例外ではなくもっとシンプルな使い方
method_missingも例外みたいなもんだしね
601 :仕様書無しさん2012/05/03(木) 02:20:31.10
>>598
それより、ここ一年で何作ったんだよお前は
594 :仕様書無しさん2012/05/02(水) 22:24:17.53
uyはゲームが、ゲームがとやたら拘ってたが
そろそろまともに遊べるゲームの1つでもできたのか?
まさか、未だオセロとかそんなレベルじゃあるまいな。
596 :仕様書無しさん2012/05/02(水) 23:32:28.94
その阿呆に釣られてOOの話を続けてる莫迦も
さっさと首括ってくればいいのに。
597 :仕様書無しさん2012/05/02(水) 23:42:14.09
マ板にはアホだろうがなんだろうが全力で相手する暇人が多いからな
他では速攻切り捨てられるから結局相手してくれるヤツが居るマ板に戻ってくるんよな
んで自爆するまで糞みたいな自説披露してしばらく沈黙
しばらくしたらヒキニートゆえに人恋しくなって(笑)またご来訪

この繰り返し


某スレに居着いてる別のレス乞食な屑コテも同様に
相手する馬鹿が居るからこの板に依存(笑)
攻撃されたらキレるが相手にされないと拗ねるのはこの子と同じ
まあそれなりに需要と供給が成立しているということなのだろう
600 :仕様書無しさん2012/05/03(木) 02:19:29.65
Google Goや、純粋OOP型であるVisual Works、
Pharoに例外機構が無いのに何言ってんだ?

例外処理自体はするけど、Cの例外処理と
似たようなもんだし
604 :仕様書無しさん2012/05/03(木) 07:38:50.06
visual worksにもpharoにも例外機構はあるが…
610 :仕様書無しさん2012/05/03(木) 13:46:55.60
>>604
参考にその例外機構を使ったコード書いてみて
612 :仕様書無しさん2012/05/03(木) 14:05:24.66
>>604
汎用的なシグナル・ブロック・通常のメッセージ式の組み合わせで
ライブラリとして例外処理出きるようになってるだけで、
専用の例外機構なんてなくね?
616 :仕様書無しさん2012/05/03(木) 16:20:11.60
>>612
MethodContextのソース読んでみるヨロシ
606 :仕様書無しさん2012/05/03(木) 08:29:13.01
シェルスクリプトにも
例外相当のものがあるというのに。
607 :仕様書無しさん2012/05/03(木) 08:32:55.72
例外の考え方としては、

エラーが発生したらデフォルトで本来の流れと違うコードに飛ぶというもの

これの利点は、想定外の事例が発生した時に
(エラーってのは大抵想定外)、そのまま処理が進むないということ。

何も書かない状態で安全な動きをするというのがメリット。
608 :仕様書無しさん2012/05/03(木) 08:55:28.23
例外は第3の選択肢であって、想定していない事象を握りつぶすことじゃないよ。
609 :仕様書無しさん2012/05/03(木) 11:02:25.44
そりゃ想定してないのを握りつぶしたらダメだろw
なんでわざわざ握りつぶすんだ?
614 :uy2012/05/03(木) 14:29:41.16
>>609
Rubyで俺は、例外使うときにそういう使い方をしてるよ
利点としては、いちいちエラーの原因探るのがめんどくさいんだけど、なんか稀にエラーが出ちゃう場合に、
とりあえず例外で飛ばして次の処理にいく
そんなかなりアバウトなプログラミングが出来る
俺はこれを最近とあるマルチスレッドプログラミングで行った

500の何かがあった場合に、その中からエラーを出さずに使えるものだけ使い
ある処理をする場合にエラーの原因を探らずにプログラミングを続行するために例外を使った
630 :仕様書無しさん2012/05/04(金) 02:19:48.47
>>620
やっぱりuyは馬鹿だな。全然理解できないじゃん
>>615,617,618は結局全部間違いの指摘だろ
あの>>614の内容じゃ、俺馬鹿ですよ叩いてくれって言ってるようようなもんじゃないか
それとも、今度もまた以前の発言捻じ曲げて、都合よく解釈して自己弁護するの?

> それともチンコで釣りするのが趣味なのか?
641 :仕様書無しさん2012/05/04(金) 08:26:06.88
>>614をしたり顔で書いてるの想像すると笑ってしまう
615 :仕様書無しさん2012/05/03(木) 14:43:29.96
> 利点としては、いちいちエラーの原因探るのがめんどくさいんだけど

あぁ、俺も面倒くさい時は
信号無視とかやるよ。

でも今は、間違ったことをやるって話じゃないんだ。
620 :uy2012/05/03(木) 23:51:11.10
理解してる>>615と理解してない617,618の違いはなんだ

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

俺がお前に教えてやるレベルだからじゃね?
618 :仕様書無しさん2012/05/03(木) 21:41:03.73
つか、必要だからそのルート通るんでしょ?何から問題があったとして
そこをぶっ飛ばすなんて、その先まともに動くのかね?よしんば動いたと
しても、それって自分で作ったもんをコントロールできてねーんじゃ?
622 :uy2012/05/04(金) 00:05:42.53
へー

ただ単純に結果だけがほしい時であれば
再現性が少ないエラーやバグを、いちいち調べないってのが本当の所

rubyだとgemで落としたらライブラリにバグもあったりするし、文字コード関連や型エラーなど
そういうものを、よく考えずにすっ飛ばしてどうにか動くようにする為に例外使うこともある
この使い方は、元々の例外の使い方じゃなくて副産物なんだろうね
けど便利に使わせてもらってるよ
623 :uy2012/05/04(金) 00:07:12.08
どうせ社畜プログラミングしかやってない子にはわからないんだから、
わからないものはスルーすればいいのに

2chの全部のレスから疑問をなくさなくちゃ気がすまないのか?
uyは何を言っているんだろう、よくわからないや で終わらせればいいのに
邪魔だと思うぞ、そういうのは
635 :仕様書無しさん2012/05/04(金) 02:32:41.64
>>623
>わからないものはスルーすればいいのに
そうやってわからない(理解できない)例外を全部スルーしてるってわけか

うちの数ヶ月で切られたゴミ中途も同じようなことしてたなw
628 :uy2012/05/04(金) 02:07:12.34
629 :仕様書無しさん2012/05/04(金) 02:11:40.81
>>628
お前は毎日日曜日だろ?w
632 :仕様書無しさん2012/05/04(金) 02:25:22.94
糞コテは相手するだけ無駄だからスルーしとけ。
何言っても最後にレスした方が勝ちだと思ってるから、何かしら反応してくるし邪魔。無視が一番。
633 :仕様書無しさん2012/05/04(金) 02:26:16.11
存在自体が例外みたいな屑ニートが例外扱いはダメって
自分をドロップアウト扱いするなって言ってるみたいで笑えるよね
637 :仕様書無しさん2012/05/04(金) 02:53:28.45
また暴れるようなら再度過去のイタい発言集をテンプレにした隔離スレをたてるだけだな
638 :仕様書無しさん2012/05/04(金) 02:56:14.38
例外が発生した時にその後の処理をすっ飛ばしたら問題だろ、
と言って例外を批判するやつは、例外を使わなくてもエラーコードをチェックして
その後の処理をキャンセルするコードをせっせと量産しているという事実を
見逃しているからフェアな比較ができてないだけ。
そしてエラー処理を入れ忘れてバグると。例外をつかったほうが逆に安全、というのは直感に反するところもあるが事実だ。
649 :仕様書無しさん2012/05/06(日) 10:19:33.46
>>638
>見逃しているからフェアな比較ができてないだけ。
>そしてエラー処理を入れ忘れてバグると。

処理書いてるからフェアかどうかって話ではないでしょ。
でもって例外だって例えばキャッチし切らずに抜けること
あるじゃん?でより上位の例外処理でつかんじゃって解析に
手間取ったり。

間抜けな話だがまぁそこまでいくと、どこ
までを処理の中
で想定できてるか、どこまで問題をとりのぞけるかっちゅー
話になってくるけどね。

一緒だよ。
650 :仕様書無しさん2012/05/06(日) 12:09:05.68
>>649
デフォルトで処理が止まるのと進むのと、どっちが問題を起こしやすいか、
問題が潜在化・深刻化しやすいか、考えてみたら違いがわかるでしょ。
640 :仕様書無しさん2012/05/04(金) 03:13:53.15
例外スレらしいオチも付いたところで、糞コテを補足して処理するのもこれくらいにしておこうか。
ここでは復旧できる見込みのない例外だし、ロギングもしたから再スローするのが正しい。
643 :仕様書無しさん2012/05/05(土) 22:54:07.49
他人にソフト公開してる訳でもないクソコテにつきあうお前らってやさしいな
そのままちゃんと隔離しといてくれよ
644 :uy2012/05/06(日) 01:17:42.20
思うんだけど、俺がレスをしないとスレ停止してんだけど

たのしいかこれ
647 :仕様書無しさん2012/05/06(日) 03:48:24.15
元々過疎スレでたかが1日レスが無かったぐらいで何の問題が?
648 :仕様書無しさん2012/05/06(日) 03:56:58.84
診断基準(アメリカ精神医学会 DSM-IV)

『自己愛性人格障害』Narcissistic Personality Disorder
誇大性(空想または行動における)、称賛されたいという欲求、共感の 欠如の広範な様式で、
成人期早期までに始まり、種々の状況で明らかになる。以下の5つ(またはそれ以上)によって示される。

 (1) 自己の重要性に関する誇大な感覚(例:業績やオ能を誇張する、
     十分な業績がないにもかかわらず優れていると認められることを期待する)。

 (2) 限りない成功、権力、才気、美しき、あるいは理想的な愛の空想にとらわれている。

 (3) 自分が特別であり、独特であり、他の特別なまたは地位の高い人達に
     (または施設で)しか理解されない、または関係があるべきだ、と信じている。

 (4) 過剰な賞賛を求める。

 (5) 特権意識つまり、特別有利な取り計らい、または自分の期待に自動的に従うことを理由なく期待する。

 (6) 対人関係で相手を不当に利用する、つまり、自分自身の目的を達成するために他人を利用する。

 (7) 共感の欠如:他人の気持ちおよび欲求を認識しようとしない、またはそれに気づこうとしない。

 (8) しばしば他人に嫉妬する、または他人が自分に嫉妬していると思い込む。
651 :uy2012/05/07(月) 20:14:21.30
今ちょっと、
これから有名になって使われるであろうプログラミング言語の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
>例外処理やクラスの継承、ジェネリックプログラミング、アサーション、オーバーロードといった機能が存在しない

らしいですよwwwwwwwwwwwwwwww
例外厨涙目wwwwwww

Googleのwwwwww博士級の人達がwwwwwwww例外はいらないと言ったんですねwwwwwwっうぇwwwwww
655 :仕様書無しさん2012/05/07(月) 22:57:55.44
>>651
悪い悪い。訂正しておいたよ。

> クラスの継承、ジェネリックプログラミング、アサーション、オーバーロードといった機能が存在しないことも特徴として挙げられる。
> try-catchはないがそれに代わる機能としてpanicとrecoverを用いた例外処理をサポートしている。[2]
> FAQにおいて、ジェネリックプログラミングは一部導入が表明されているが、オーバーロードは効率的見地から排除されたことが述べられている。
> 関数は多値を返すことができるので、それによりエラーの報告は容易である、としている。
668 :仕様書無しさん2012/05/08(火) 21:24:05.48
>>655 どうでもいいがtry-catchだろうが、recoverだろうが例外処理って書いてるのおかしくないか?
こういうのは、あくまで例外機構であって、例外処理は人間が書くものじゃね。
652 :uy2012/05/07(月) 20:21:22.28
そりゃそうだよねーーー
いらないよねーー
このあたりはJava(笑)と違って流石Googleかなって思う

>クラスの継承
これもいらない、同意

>ジェネリックプログラミング
これもいらない、同意 メタとか動的言語でやれって話

>アサーション
は使ったこと無いな

>オーバーロード
これは静的言語ではあると便利だけど、Goの構文だとやりにくかったんだろうな
別の方法が用意されるなら良い
656 :仕様書無しさん2012/05/07(月) 23:08:34.08
英語版を参考に、もうちょっと追加したよ。

> クラスの継承、ジェネリックプログラミング、アサーション、オーバーロードといった機能が存在しないことも特徴として挙げられる。
> インターフェースを用いたポリモーフィズム(多態性)が実現されている。
> try-catchはないがそれに代わる機能としてpanicとrecoverを用いた例外処理をサポートしている。[2]
> FAQにおいて、ジェネリックプログラミングは一部導入が表明されているが、オーバーロードは効率的見地から排除されたことが述べられている。
> 関数は多値を返すことができるので、それによりエラーの報告は容易である、としている。
657 :仕様書無しさん2012/05/07(月) 23:29:41.57
Googleの中の人のプログラミングがダメダメなのは
Android携帯のできの悪さを見ればわかる。

例外だけでなくアサーションもないということは
それだけエラー処理を軽視している証拠。
659 :仕様書無しさん2012/05/07(月) 23:51:33.18
インターフェースがあってクラスの継承がないというのを見ると
VB6を思い出すね。

VB6もシェネリックもオーバーロードもないし、
あ、でもアサーションはあったな。
660 :仕様書無しさん2012/05/08(火) 07:15:02.18
マ板でtypoする奴がいるってのが信じられない
マ止めた方がいいね
661 :仕様書無しさん2012/05/08(火) 07:26:57.24
Cの代替言語で何かする気にはなれない
そういうのは組込み屋がやってろ
ScalaやれScala
663 :仕様書無しさん2012/05/08(火) 11:16:10.06
Goのdefer文とpanic-recoverの仕掛けは実際良くできてるよ。
try-catchなんか実はfinally節が必要なだけな場合も多かったりするし。
とりあえずtry-catchで囲んどけ、みたいなことがないだけマシ。
664 :uy2012/05/08(火) 17:33:37.64
一番マシなのは「;」 末尾のこれがない事だろ
; これ消すのに半世紀かかってんじゃねーよks
669 :仕様書無しさん2012/05/08(火) 21:26:24.73
>>664
枝葉末節はいいから、他人に見せられるソフト作って公開しろよ
ソフト一つ作れん言語オタクの戯言なんざどうでもいい
666 :仕様書無しさん2012/05/08(火) 19:38:41.14
uyしっとるか
BASICは「:」打つと同じ行に次のステートメントを書ける
670 :仕様書無しさん2012/05/09(水) 05:48:48.74
コードはよく出してるよなuyは。他人に見せられるかどうかは…
671 :仕様書無しさん2012/05/10(木) 10:12:16.63
すぐ例外と関係ないことに流れて自分の主張すら忘れる程度の知能しか持ち合わせてない
レスするほど価値があるか考えてから相手しろよ
676 :仕様書無しさん2012/05/12(土) 13:04:27.70
C++だと、例外はファクトリメソッド内以外ではcatchしない
オブジェクト生成時に発生した例外だけはエラー戻り値に置き換える
それ以外の場所で発生した例外はアプリ殺した方がマシ
無意味なcatchをあちこちに配置する必要なし
679 :仕様書無しさん2012/05/12(土) 15:49:42.59
>>676
えとね、コンストラクタで例外だしていいんですよ。

どっかの馬鹿本がだめとか間違ったこと
書いているのがいけないんだが。
677 :仕様書無しさん2012/05/12(土) 13:15:28.79
> オブジェクト生成時に発生した例外だけはエラー戻り値に置き換える

え? newの戻り値が、エラーになるの?
ありえんわぁw
678 :仕様書無しさん2012/05/12(土) 14:32:22.59
つか、C++の例外は途中でCがはさまったりすっとややこしいからなぁ。
680 :仕様書無しさん2012/05/12(土) 16:31:29.64
というかRAIIというベストプラクティスが一般的になる前に、「C言語禁じ手」っていう
べからず集の人気が出た勢いで書いちゃった、ろくにこなれてないC++べからず集に
書いてあったのが、その都市伝説化の発端なんだよな。
681 :仕様書無しさん2012/05/13(日) 15:05:50.71
あと、どこでcatchするかは処理次第だから、
catchするだけでNGというようなミスリードを招きそうな書き方はちょっと違う気がするな
アプリケーションとして続行可能だが、メソッドとしては例外、なんてのはいっぱいあるし
その処理で復旧可能であればその場でcatchすべきだし、
常に復旧できる処理であれば、例外復旧までを含めた処理作ってラップしてあげればいい

たまに湧く、例外に文句言ってる人は、こういったラップした処理しか作った/使ったことないから、
例外を吐く必要はないって思いこんでるんだと思うわ
682 :仕様書無しさん2012/05/13(日) 15:17:35.55
ラップされてるんならいいんだけど、ラップもせずに例外上げてくるのがむかつく。
683 :仕様書無しさん2012/05/13(日) 15:25:54.79
>>682 エラー処理めんどいってことだろ。わかるわかる。
684 :仕様書無しさん2012/05/13(日) 15:46:02.37
異常系考慮しないマほど例外を嫌うイメージ
なんか例外出たってことには気づくけど、その内容が理解できない奴も多い
685 :仕様書無しさん2012/05/13(日) 16:05:00.27
そもそも、知る必要ないものばかり投げてくるじゃん。
そういうダサすぎなプロジェクトばかりで嫌になる。
687 :仕様書無しさん2012/05/13(日) 18:33:13.18
>>685
たとえばどんな例外のこと言ってるの?
プロジェクト内の話ならお前がダサくないように修正を提案すればいいんじゃないの?
686 :仕様書無しさん2012/05/13(日) 16:09:36.02
確かに知識がないことを棚に上げて文句言ったりする奴が多いな
688 :仕様書無しさん2012/05/13(日) 21:14:17.65
例外クラス(値?)をどうデザインするか迷う。
構造がまったく同じで型情報のためだけに
クラスボコボコ作るのも面倒くさいしなぁ。

throw LexError<class Lexer::InvalidSymbol>( 色々 );

とりあえず、識別用の型をテンプレート引数に渡して
それで区別するってのが楽では有るけど、結局同じ型が
生成されてるのがなんかねぇ。
690 :仕様書無しさん2012/05/13(日) 22:11:18.47
>>688
同じ意味合いのある例外ならそういう集約の仕方はありだと思う
型が同じだと違和感があるような例外であるなら、元になる例外を継承して複数のクラスにする、とかでもいいと思う

普通にクラスを作るときと同じ感じで設計するのがいいんじゃね
同じオブジェクトとして扱うべきものかどうか、が判断条件
個人的には、クラスファイルが増えること自体は、全然面倒だとは思わない
689 :仕様書無しさん2012/05/13(日) 22:00:21.37
JavaでWeb系なら、基本的にはRuntimeException継承した業務レベルのエラー1つだけにしておくかなぁ
システムエラー的なので、RuntimeExceptionじゃない奴は
共通処理で行うように設計して、理解してる奴に担当してもらい、RuntimeExceptionでラップして投げるようにする
とにかく馬鹿にはなるべく意識させないようにしておくのが理想
692 :仕様書無しさん2012/05/14(月) 09:40:21.01
try{}
catch(...){}

何でもかんでも全てこれ。
再研修受けるか、現場から去ってくれ。
693 :仕様書無しさん2012/05/14(月) 12:36:35.32
まず、お前がそういう研修を
されたかどうか考えてみ?
698 :uy2012/05/28(月) 01:16:16.47
え、
そういえばC++からCのライブラリ使うときに例外ってどうすんですか
書き直しですか
700 :仕様書無しさん2012/05/29(火) 01:41:01.08
え、
そういえばRubyからCのライブラリ使うときどうすんですか
書き直しですか

マイクロソフト ワイヤレス ブルートラック マウス Arc Touch Mouse RVF-00006
マイクロソフト ワイヤレス ブルートラック マウス Arc Touch Mouse RVF-00006