5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

ボボボーボ・ボクは例外処理が嫌いなんだな

1 :デフォルトの名無しさん:03/11/08 23:44
他人が作ったクラスとかだと例外のキャッチし忘れ多過ぎ
何の例外が飛んでくるかわからないクラスなんて怖くて使えない

そもそも例外処理って大域ジャンプだろ、
そんなもの怖くて使えねーよ

2 :デフォルトの名無しさん:03/11/08 23:48
保守age

3 :デフォルトの名無しさん:03/11/08 23:53
↓次スレたてろ

4 :デフォルトの名無しさん:03/11/08 23:59
>何の例外が飛んでくるかわからないクラスなんて怖くて使えない
取りあえずJavaとC++では対策が既に成されてる。

5 :デフォルトの名無しさん:03/11/09 00:05
後だしじゃんけんしたくせにC#はいまだに対策がとられておらず


6 :デフォルトの名無しさん:03/11/09 00:07
アホアンチはこなくていいよ。

7 :デフォルトの名無しさん:03/11/09 05:15
対策ってどんなの?

Rubyつかってるからわからないけど、なにかあるなら教えて。

8 :デフォルトの名無しさん:03/11/09 05:16
>>7
メソッドに何が飛んでくる可能性があるか書いてあるだろが。

9 :デフォルトの名無しさん:03/11/09 05:31
>>3
次スレです。
http://pc2.2ch.net/test/read.cgi/tech/1065535118/

10 :デフォルトの名無しさん:03/11/09 05:41
C++の例外処理は遅い

11 :デフォルトの名無しさん:03/11/09 05:43
>>10
頻繁に呼ぶもんじゃないし、いいんじゃないの。

12 :デフォルトの名無しさん:03/11/09 05:43
>>10
例外とはめったに起こらないから例外なんだから遅くてもいいだろ

13 :デフォルトの名無しさん:03/11/09 07:24
統合環境使えば可能性のある例外全部教えてくれるけど、
言語自体にも対策方法があるの?

14 :デフォルトの名無しさん:03/11/09 07:26
例外が遅いから分岐にしているだけじゃないか?
本来は例外として分類されるべき処理はいくらでもありそうだが


15 :デフォルトの名無しさん:03/11/09 07:41
>>14
そんなに速度が要求されるのに例外にされるべき処理って何?

16 :デフォルトの名無しさん:03/11/09 07:51
例外処理を使うと処理の流れというか思考の流れが飛ぶので気持ち悪い

17 :デフォルトの名無しさん:03/11/09 07:54
正常系と例外系で分けて考えられるから見通しが良くなると思うんだが。

18 :デフォルトの名無しさん:03/11/09 07:56
例外の方が重要なのに。おまえらわかってない。


19 :デフォルトの名無しさん:03/11/09 07:58
効率重視ならいきなりthrowより
goto先にまずまとめたりしない?

20 :デフォルトの名無しさん:03/11/09 07:59
あ、VBのGotoErrorラベルみたいなやつね。
VBっていうと敬遠されるかもしれんけど(w

21 :デフォルトの名無しさん:03/11/09 08:07
副作用が主の手続きは返すべき値が無いので、
自然と正常系以外は全て例外扱いになるが。


22 :1:03/11/09 08:49
>>17
今仕事で修正しているプログラムはただでさえぐちゃぐちゃなのに
例外処理使われていて目も当てられない
その上、キャッチのし忘れも多過ぎ
百戦錬磨の俺でさえ逃げ出したくなる。もう例外キライ

本来、エラー処理の抜けをなくしたりシンプルに扱うための例外処理だった
はずなのに、実際は抜けは多くなるし流れも見えづらい
俺にはGOTO文より極悪に見えて仕方がない

23 :デフォルトの名無しさん:03/11/09 09:34
>>20
途中スコープの外れるインスタンスのデストラクタを読んでくれたりかなり高機能ですけどね。

24 :デフォルトの名無しさん:03/11/09 09:35
後、例外が構造化できるのがポイント。
VBのそれにはまねできないわけだ。

25 :デフォルトの名無しさん:03/11/09 12:02
C++は文法的になんの例外投げるのかとか知ることができないのがつらいね。
一応、メンバ関数の宣言の後ろにthrowをつけれるけど、
あってもなくてもコンパイルできちゃうわけで。

26 :デフォルトの名無しさん:03/11/09 12:12
>>25
付けてもVCはthrow() (例外を投げない宣言)以外は未実装警告だして
使えないしね・・。VC7.1のISO仕様残り2%のひとつだ。

27 :デフォルトの名無しさん:03/11/09 13:21
C#でゲーム作っててさ、
オブジェクトの終了を通知するための手段として
例外を使ってるんだわさ。
で、例外を受け取った外側の処理でそのオブジェクトへの
参照を外すようにしてる。
こういう使い方ってしないほうがいいのかな・・・?

28 :デフォルトの名無しさん:03/11/09 13:23
>>1
>そもそも例外処理って大域ジャンプだろ
例外処理を勘違いしてそんな書き方するやつがいるだけだ

29 :デフォルトの名無しさん:03/11/09 13:27
>>25
へーそうなのか、C++はコンパイルとおっちゃうのか
そりゃあわけわからんプログラマが前工程やるとわけわからんくなるわな

30 :デフォルトの名無しさん:03/11/09 13:31
>>27
そういう例外の使用法は、よく悪い例として取り上げられています
C#は詳しくないけど、デストラクタってありましたよね?

31 :27:03/11/09 13:40
>>30
デストラクタはありません。(ファイナライザはありますが…)
C#では基本的にGCがメモリの後処理をしてくれます。

やはり例外を通常処理として用いるのは良くないのですか?

32 :デフォルトの名無しさん:03/11/09 13:43
例外人間

33 :デフォルトの名無しさん:03/11/09 13:51
>>31
>やはり例外を通常処理として用いるのは良くないのですか?

これは当たり前として。


34 :27:03/11/09 14:08
>>33
わかりました。bool値を返すように変更します。

35 :デフォルトの名無しさん:03/11/09 14:16
じゃあC++でlongjmpの真似事をするにはどうすればいいんだ

36 :デフォルトの名無しさん:03/11/09 14:33
実際、何を勘違いしているのか、例外を正常な動作の分岐用フラグのつもりで
使うというやつがいて困ったことがあるなぁ

呼べば、ほとんど確実に例外を投げるという・・・ カンベンしてくれ。

37 :デフォルトの名無しさん:03/11/09 14:48
まあ、どこまでが正常処理でどこからが異常処理かと言うのは個人差があるからな。

「ほとんど確実に例外を投げる」と言うのは、ちょっとおかしいと思うけど。

38 :デフォルトの名無しさん:03/11/09 14:50
名前が悪いんだよ
例外機構じゃなくて大域脱出機構にでもすればよかったんだよ。

39 :デフォルトの名無しさん:03/11/09 14:53
>>13
この世に使っているすべてのプログラマが統合開発環境を使っているとは限らないので
そういうものに頼る手法は却下

40 :デフォルトの名無しさん:03/11/09 14:55
例外処理を効率よく処理できるデザインパターンを教えれ。
またはそのサイトや書籍をおしえれ

41 :デフォルトの名無しさん:03/11/09 14:58
無い

42 :デフォルトの名無しさん:03/11/09 14:59
なんかあるだろ。
例外に特化した本でなくてもいい。
なにかおすすめがいい。
鉄則本や落とし穴本でもいい

43 :デフォルトの名無しさん:03/11/09 15:04
そもそも例外機構とOOに関連性はない。
例外処理の手順について理解を深めろ。

44 :デフォルトの名無しさん:03/11/09 16:24
ある処理を実行してる最中にその処理の続行が完全に不可能になった時、例外を
生成して開放が必要なオブジェクトを廃棄し処理を停止させてるけどだめ?


45 :デフォルトの名無しさん:03/11/09 16:40
ところでJava以外で例外処理なんて使ってる人いるの?

46 :デフォルトの名無しさん:03/11/09 17:49
>>40
例外とは関係ないけど,もしかしたら
"NullObject パターン" を挙げると喜ぶ?

47 :デフォルトの名無しさん:03/11/09 22:35
あれは例外に適しているものだったのか?
投げるべき例外をしっかりとつかみちゃんと正しく例外が処理されるのか?


48 :デフォルトの名無しさん:03/11/09 23:00
例外処理ってsignal(3C)がsigaction(2)でしょ。
Windowsは知らんのだが、言語で処理するのは
あまり好きくなれん

49 :デフォルトの名無しさん:03/11/10 01:39
>>48
それは普通割り込みという

50 : :03/11/10 01:49
嫌い「なんだな」 ← なんだこれ

51 :デフォルトの名無しさん:03/11/10 01:52
>>50
裸の大将じゃないの?

52 :デフォルトの名無しさん:03/11/10 15:48
>>50
一般常識に疎いということはオタクだろ、お前。

53 :デフォルトの名無しさん:03/11/10 16:47
ボーボボの喋りに特徴ないとは言え、スレタイのわりに1の本文普通すぎ。

54 :デフォルトの名無しさん:03/11/10 22:52
>>52
純粋に若いだけかも。何年前だよ、裸の大将って

55 :デフォルトの名無しさん:03/11/11 23:54
>>22
仮に例外処理以外の方法(エラーコードを戻り値で返したりグローバル変数に格納したり)
を採用したところでその環境じゃまともに機能しないだろ。
責任を例外処理に押し付けたところで何も問題は解決しない。

例外を投げるやつはドキュメントに明記しろ。
メソッドをコールする奴はドキュメントを嫁。ただそれだけ。



56 :デフォルトの名無しさん:03/11/12 00:09
mainでcatch(...)すれば無問題

57 :デフォルトの名無しさん:03/11/12 09:57
結局throwsという実験的機能は失敗に終わったということでFA?

58 :デフォルトの名無しさん:03/11/12 10:04
>>55
Javadocならthrows句で宣言した例外クラスを書き出してくれるよ。
>>57
ということにしたいのですね :-)

59 :デフォルトの名無しさん:03/11/12 10:42
>>46
喜べるとはいえない。。もしそれが逆ならギャグいわれたってそれだけでは現実には何も進展がない。

Javaの鉄則に、「例外を隠さない」手法として
Vectorにcatchされた例外を詰め込んで最後に吐き出し表示するという技が
あった。
しかし汎用性が感じられなかったなあれは。
既存の数多くの例外クラスにそんな機能が最初から
そなわっていればあんなつかいかたも考慮したのだが・・・。

Throwableクラスのメソッドをどうにかして使えばいいのか・・?

60 :デフォルトの名無しさん:03/11/12 10:55
裸の隊商はボーボボよりマイナーになったか。

61 :デフォルトの名無しさん:03/11/12 11:14
少なくともJavaに関して言えば例外は非常にうまく機能してるんじゃないの?
逆にC#の例外書かなくてもコンパイル通っちゃうのは不安でいけない。
って書くとまた荒れる元になるかな。

62 :デフォルトの名無しさん:03/11/12 11:21
throws Exception相当だからね。

63 :デフォルトの名無しさん:03/11/12 13:46
れれれれれれれれれれれれれれ例外!!
ああっ!!出ちゃう!!例外出ちゃいますぅぅぅぅぅぅ!!!!!!!

ということで
----------------------終了-----------------------

64 :デフォルトの名無しさん:03/11/12 14:27
まるでお粗末君のれれれのおじさんみたいだ。

65 :デフォルトの名無しさん:03/11/15 01:46
>>64
ニャロメとケムンパスはいたと思ったが・・・。

66 :デフォルトの名無しさん:03/11/20 12:25
>>18
何言ってんですか?

67 :デフォルトの名無しさん:03/11/20 13:21
>>65
おそまつにもいるよ。ほうきをもったやつだろ

68 :デフォルトの名無しさん:03/11/21 00:27
>>59
メンバにList<Exception>を持つExceptionサブクラス作ったら?
printStackTrace()とかオーバーライドしといて、あとListへの
Iteratorを返すメソッド追加しとけば、そこそこ便利じゃないかね。

つうか、俺がそういうの使ってる。

69 :デフォルトの名無しさん:03/11/21 07:16
Listである必要はないだろ。
ひとつ上への参照さえもてれば連鎖的に保存しておけるんだから。

つうか、MSがそういうの使ってる。

70 :デフォルトの名無しさん:03/11/22 18:50
つーかC++って構文無茶苦茶汚いね。
何が
List<Exception>
だよ。
おまえらそれで満足か?

71 :デフォルトの名無しさん:03/11/23 09:58
>>70
ええ、その後に数十回同じキャストを繰り返すよりは。

72 :デフォルトの名無しさん:03/11/23 16:10
>>70
>List<Exception>
充分、きれいですが。


73 :デフォルトの名無しさん:03/11/23 17:16
White Spaceの美しさは半端じゃない

74 :デフォルトの名無しさん:03/11/24 03:20
>72
馬鹿やろ
破綻してるだろうが。

List<List<Exception>>

これでもうだめぽ(ゲラ

75 :デフォルトの名無しさん:03/11/24 08:14
それ、コンパイルエラー。

List<List<Exception> >

だと思われ。



76 :デフォルトの名無しさん:03/11/24 13:58
>>75
だから>>74は破綻しているといっているのではなかろうか。

77 :デフォルトの名無しさん:03/11/25 01:52
>>75
ほっとけよ、XXXX房は。
唯一C++のtemplateに勝てる所なんだから。
そっとしておいてやっれって。


78 :デフォルトの名無しさん:03/11/25 02:30
例外って本当に有効?
例外の利点でよくでるのがスタック等のオブジェクト
破棄や、コールスタックさかのぼっていけるって言うけど、
オブジェクトの破棄はされても関数呼び出しの効果が
自動的ににロールバックされるわけでもないし。
例外のせいで中途半端なところで関数呼び出しが終わってしまう
可能性を絶えず考慮してコーディングする労力のほうが便利さを
遥かに上回っているようなきがする。

例外的な状況のために全ての関数でとりあえずcatchして
ロールバック処理&再throwを書くのもめんどう。

79 :デフォルトの名無しさん:03/11/25 02:45
>78
初歩で陥るとこだ罠

80 :デフォルトの名無しさん:03/11/25 03:31
>>78
ルーティングの段階でロールバック。
ロールバックの必要な処理は型やメンバでフィルタリング。
try {
....
} catch (filter &e) {
rollback();
thorw;
}

81 :デフォルトの名無しさん:03/11/25 03:34
>>78
お前のコードの中にfinallyってあるか?
無ければ独習シリーズでも読み直して出直せ。


82 :デフォルトの名無しさん:03/11/25 04:38
つーか例外めんどくせい。俺のコードには
try {
 foo();
} catch(...) {
//何もなし
}
というコードばっかりだよ。

いっそのことこう書こうかなw
try { foo(); } catch(...){}

83 :デフォルトの名無しさん:03/11/25 04:50
>>82の書くプログラムは正直使いたくないと思いました。

84 :デフォルトの名無しさん:03/11/25 05:00
だっていちいち例外かけって言われるからこうするしか無いじゃん。

85 :デフォルトの名無しさん:03/11/25 05:01
だいたい、雑誌とかもこんな風に書いてるしな。

86 :デフォルトの名無しさん:03/11/25 06:49
>>78
>自動的ににロールバックされるわけでもないし。

されたら迷惑

87 :デフォルトの名無しさん:03/11/25 06:50
>>82
スタックトレース位吐けやボケ。

88 :デフォルトの名無しさん:03/11/25 07:11
>>87
禿道。例外発生したらスタックトレース。
決り文句。常にこう書くべし↓

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

例外発生時にも処理が続行されるがキニシナイ

89 :デフォルトの名無しさん:03/11/25 07:42
>>87がスタートレックにみえた_| ̄|○

90 :デフォルトの名無しさん:03/11/25 09:41
>>82
くたばれ

91 :デフォルトの名無しさん:03/11/25 10:21
>>81
finallyなんてねえよ。あったらコンパイルとおらんし(w

>>86
>されたら迷惑
もちろんめいわくだ。何が正しいロールバックかなんて
機械的に決定されるものでもないと思うし。例外が自動で
やってくれることはたかが知れているじゃないかって意見。

本当に末端のライブラリが投げるんならまだ良いんだけど、
アプリケーション製作者が気軽に投げるもんでも無い気が
する。


92 :デフォルトの名無しさん:03/11/25 14:19
Java厨は氏んでいいよ。

93 :デフォルトの名無しさん:03/11/25 14:23
漢なら確固たる信念を持って例外処理すべし。
try {
 foo();
} catch (...) {
 throw;
}
これで決まりではないか。

94 :デフォルトの名無しさん:03/11/25 20:45
あー、C++なのか。
あれだけゴチャゴチャした言語仕様なのに、finallyが無いってのは
けっこうビックリだよな。
最近じゃVB.NETにすら付いたのに。


95 :デフォルトの名無しさん:03/11/25 20:59
>>94
デストラクタで各オブジェクトに後始末させるからいいんじゃないの

96 :デフォルトの名無しさん:03/11/25 21:23
newとdeleteそのまま書くのって、
Cでmallocやfree呼んでるのと実質変わらないよね。
reallocが無い時点でC++はゴミ。
例外機構なんてやめてlongjmp駆使した方が速いしわかりやすい。
longjmpでデストラクタ呼ばれないのはもうね、馬鹿(略

97 :デフォルトの名無しさん:03/11/25 21:40
>>78
だな。
出口や入り口は少なければ少ないほど理解しやすくいいと言われてるのに、
例外処理はそれに完全に逆行してる
少なくてもC++では流行る気配すらないな

98 :デフォルトの名無しさん:03/11/25 21:46
>>97
>出口や入り口は少なければ少ないほど理解しやすくいいと言われてるのに
気のせいです。

99 :デフォルトの名無しさん:03/11/25 21:56
>>97
途中でリターンというのは、途中で一つの出口へのgotoと同じ事なのだよ。

int foo(void) {
 int ret;
 if(A) {ret=1; return ret;}
 if(B) {ret=2; return ret;}
 if(C) {ret=3; return ret;}
 ret=0;

 return ret;
}
   ↓
int foo(void) {
 int ret;
 if(A) {ret=1; goto end;}
 if(B) {ret=2; goto end;}
 if(C) {ret=3; goto end;}
 ret=0;

end:
 return ret;
}

関数の終わりの}の直前に飛んでいるだけなのさ。だから途中でreturnも出口は一つ。

100 :デフォルトの名無しさん:03/11/25 21:59
関数型で書けよ。制御を終わらす意味でのreturnなんか無いぞ。

101 :デフォルトの名無しさん:03/11/25 22:25
関数型には例外処理があんのか?

102 :デフォルトの名無しさん:03/11/25 22:54
>>99
今度は、そんな goto だらけのプログラムは、理解しにくいと言われるだけだぞ。

103 :デフォルトの名無しさん:03/11/25 23:01
>>102
空気読んでよく読め

104 :デフォルトの名無しさん:03/11/25 23:40
>>96
reallocワラタ

>>101
あるよ。MLは例外にも例外が返る関数にも厳密な型がついているよ。

105 :デフォルトの名無しさん:03/11/26 00:37
例外嫌いなC++屋は、まぁこれでも読んで出直せや。
ttp://boost.cppll.jp/HEAD/more/generic_exception_safety.html

106 :デフォルトの名無しさん:03/11/26 00:43
例外はスレッドと相性悪いんだよなあ・・
理をうまく実践できない

107 :デフォルトの名無しさん:03/11/26 00:52
手続き型と例外は相性が悪い。

{
a();
b();
c();
}
aを呼んだらcは必ず実行しなければならない。
cを実行しなかった場合の動作は未定義であるとする。
こういう場合、bで例外が投げられたらプログラムは安全に続行不可能
という意味で破綻する。クラスに置き換えても同じだ。

{
o->a();
o->b();
o->c();
}

オブジェクト指向はこの問題を解決しない。
(C++の自動デストラクタに頼るしかない。これはOOとは何の関係もない)

108 :デフォルトの名無しさん:03/11/26 01:00
>>106
そうかい?
C++例外+pthread+UNIXなら相性悪いと思うけど、
例外+スレッド一般は特に問題ないだろ。Javaとかね。

非同期I/Oやスレッドプールが絡むと嫌らしいけどな。

109 :デフォルトの名無しさん:03/11/26 01:10
>>107
ばかだなぁ。

{
try{ a(); } catch(...){}
try{ b(); } catch(...){}
try{ c(); } catch(...){}
}

とすれば手続き型と全く同じですよw

110 :デフォルトの名無しさん:03/11/26 01:11
あわわ・・

111 :デフォルトの名無しさん:03/11/26 01:12
×とすれば手続き型と全く同じですよw
○とすれば例外を使わない場合と全く同じですよw



112 :デフォルトの名無しさん:03/11/26 01:19
まさか関数全てを
try{ ... } catch(...){}
で囲むバカはおるまい。

113 :デフォルトの名無しさん:03/11/26 01:20
>>112
b()だけでいいだろ。真馬鹿め。

114 :デフォルトの名無しさん:03/11/26 01:22
107のような場合は例外ならfinallyを使えばいいしな。
例外は常に例外じゃない方法よりも便利。

115 :sage:03/11/26 01:29
例外って便利か?
そりゃ例外使っても良い作りのプログラムにしとけばいいけど
そうするための苦労に比べ実入りが少ない気がする。

しかし、C++にfinallyが無いのは悲惨だな
RAIIへの配慮が足りないぞ

>>46
NullObjectというのはイイ手だよね

>>101
MLにはある。Haskellにも導入されそう。Lisp、Schemeにはない。
ただしSchemeでは継続をつかって例外処理することができる。

116 :デフォルトの名無しさん:03/11/26 01:32
別にfinallyがなくてもtryの外に書けばいいだけだろ。

117 :デフォルトの名無しさん:03/11/26 01:36
> しかし、C++にfinallyが無いのは悲惨だな
> RAIIへの配慮が足りないぞ

finallyがあったら、RAIIを実践するにあたってどんな利点があるのですか?

118 :デフォルトの名無しさん:03/11/26 01:48
>>115
> 例外って便利か?
> そりゃ例外使っても良い作りのプログラムにしとけばいいけど
> そうするための苦労に比べ実入りが少ない気がする。

言語に例外機構があることで、例外について考える圧力が生じ、
それで、例外が「大変だ」と思う人がいるんじゃないかな。

言い換えれば、今まで例外処理をいい加減にやって来たから、大変だと思うのでは。

実際、例外機構のない言語では、例外処理の選択肢が狭く、
それを逸脱しようとすると大変なことになる。

つまり、例外機構のおかげで、例外処理に幅が出たのでは?

119 :デフォルトの名無しさん:03/11/26 01:52
>>118
僕ちゃんは何がどう大変になるんだい?

120 :デフォルトの名無しさん:03/11/26 06:44
>>96
reallocワラタ
でもたしかreallocみたいなことをできるOOPLなかったっけ?

121 :デフォルトの名無しさん:03/11/26 06:49
>>113
bだけでいいとか言い出すと、次はtryで囲む事自体忘れる奴が現れる
そうなると、従来のif文によるエラーチェックを忘れるよりタチが悪い

122 :デフォルトの名無しさん:03/11/26 09:56
>>119
簡単なんで、例外処理、あれもこれもやりたくならないかい?

123 :デフォルトの名無しさん:03/11/26 10:05
>>115
> しかし、C++にfinallyが無いのは悲惨だな
> RAIIへの配慮が足りないぞ
逆じゃないの?コンストラクタ・デストラクタでRAII
を簡単にサポートできるから、finally無くても
破綻しないじゃないの?

void func() {
fstream file("file.txt");
//若しくは auto_ptr<fstream> file=new fstream("file.txt");
throw Exception;
}


124 :デフォルトの名無しさん:03/11/26 13:24
例外かくとき
try {
 //処理
} catch(FirstException e){
 e.printStackTrace();
 throw new FirstException(e);
} catch(SecondException e){
 e.printStackTrace();
 throw new SecondException(e);
} catch(Exception e){
 e.printStackTrace();
 throw new Exception(e);
} とすべきか
try {
 //処理
} catch(FirstException e){
 e.printStackTrace();
} catch(SecondException e){
 e.printStackTrace();
} catch(Exception e){
 e.printStackTrace();
} とすべきか
try {
 //処理
} catch(FirstException e){
 throw new FirstException(e);
} catch(SecondException e){
 throw new SecondException(e);
} catch(Exception e){
 throw new Exception(e);
} とすべきかで迷う

125 :デフォルトの名無しさん:03/11/26 13:53
何がやりたいんだか理解できないが、スタックトレース吐いて
同じ例外投げたいんだったらこれでいいだろ。

try {
// 処理
} catch(Exception e) {
e.printStackTrace();
throw e;
}


126 :デフォルトの名無しさん:03/11/26 18:28
124は例外の前にポリモフィズムをまず勉強すべきだな

127 :デフォルトの名無しさん:03/11/27 00:33
>>124,125
Java?

128 :デフォルトの名無しさん:03/11/27 04:32
Polymorphism だからポリモルフィズムでもポリモフィズムでも
どっちでも読めるんですね。一瞬まよってしまった。

129 :デフォルトの名無しさん:03/12/03 22:31
>>121
class foo {
private:
 void a(...);
 virtual void b(...);
 void c(...);
public:
 void bar(...);
};

void foo::bar(...){
 a(...);
 try {
  b(...);
 } catch(...){
 }
 c(...);
}

ってやっときゃいいだけだろ。

130 :デフォルトの名無しさん:03/12/06 07:33
>>129
Zyaaそもそもプロトタイプ宣言すんなよ。と。


131 :デフォルトの名無しさん:03/12/06 23:39
>>130
・誤爆。
・単なる釣り。
・単なるアフォ。

どれなんだ ?

132 :デフォルトの名無しさん:03/12/07 00:37
どーでもいいがこのスレタイはボボボーボ・ボーボボを意識しているのか?

133 :デフォルトの名無しさん:03/12/07 21:21
/* どーでもいいなら一々聞かないこと */

134 :デフォルトの名無しさん:03/12/08 14:48
catch(...)
{
cout << "でも聞きたい" << endl;
}

135 :デフォルトの名無しさん:03/12/31 01:42
ShowMessage("教えてageない");

136 :デフォルトの名無しさん:04/01/03 06:05
sine

137 :デフォルトの名無しさん:04/01/03 11:01
.NETの例外は恐くて使えない

138 :デフォルトの名無しさん:04/01/03 12:28
>125
お前リリース品にもprintStackTraceみたいなデバッグプリント入れてるバカだろ。

139 :デフォルトの名無しさん:04/01/03 22:04
>>138
お前日本語読めない馬鹿だろ。
しかもageてるし。

140 :デフォルトの名無しさん:04/01/04 00:42
ん? あげるとバカ呼ばわりされるのか?

141 :デフォルトの名無しさん:04/01/04 01:06
>>140
お前日本語読めない馬鹿だろ。

>>139は「日本語読めない」から「馬鹿だ」って言ってるんだろうが。


142 :デフォルトの名無しさん:04/01/04 14:55
>>138
ん、なんだ、125って俺の書き込みじゃん。
ということはお前は124?


143 :デフォルトの名無しさん:04/01/04 16:18
.NETの例外は何飛んでくるか分からない。
怖い。


144 :デフォルトの名無しさん:04/01/05 01:28
俺もC#始めたが、throws節無いのは怖い。
try catchを厳密に求められるJavaは面倒くさいとも思うし、
そこらへんいい加減でもプログラムが組めるのはやってわかったが、
言語が例外処理漏れを確実に防いでくれる方がトータルで低コストだ。


145 :デフォルトの名無しさん:04/01/05 08:09
>>144
なんか同意。VBとかK&R Cとか曖昧性のある言語って高コストっす。

146 :デフォルトの名無しさん:04/01/05 20:53
>>91
boostにもfinally相当がないの?

147 :デフォルトの名無しさん:04/01/05 20:54
>>146
テンプレートでどうにかなる問題なんですか?

148 :デフォルトの名無しさん:04/01/05 20:57
>>138
フレームワークとして使うならException#printStackTrace()いれとかんと。

149 :デフォルトの名無しさん:04/01/05 21:10
>>115

catch & throw + unwind-protect じゃだめでつか?
原始的すぎ?


150 :デフォルトの名無しさん:04/01/05 21:32
unwind-protect ?
LISPの話をしているのか?

151 :デフォルトの名無しさん:04/01/06 12:41
例外って人間にまともに扱えるものじゃない気がしている。
気を付けていても、どこかで内部状態の矛盾とか、資源洩れを
起こしてしまう。実は、あまり起こらないエラー、まじめな
回復をやりたくないエラーは、起こったらexit()するのが
正しいんじゃないか?
こう言うと凶悪なようだけど、スクリプト言語の世界は既にそうで、
perl/python/rubyのような汎用スクリプト言語は、「書きやすさ」
の相当部分を、「まじめなエラー処理をやらなくていい」ことで
得ている。まじめなエラー処理をやり始めたら、はっきり言って
(C++はともかく)Javaに比べて全然書きやすくない。
信頼性という面でも、まれなエラーが起こったとき、テストが不十分
であるゆえに挙動を予測できないプログラムより、直ちに異常終了
するプログラムの方が、予測可能性が高くて信頼できる。

152 :149:04/01/06 12:42
うん

153 :デフォルトの名無しさん:04/01/06 16:06
Javaのスタックトレースがデフォルトで標準出力に出るのは設計ミスだと思う。

154 :デフォルトの名無しさん:04/01/06 16:56
>>151
・・・以上ロートルアボートコア吐き厨の寝言でした。

155 :デフォルトの名無しさん:04/01/06 22:34
boostのマニュアルを見ていて、
void f(shared_ptr<int>, int);
int g();
void bad()
{
    f(shared_ptr<int>(new int(2)), g());
}
これがメモリリークになるというのを見たとき、意識が飛びそうになったよ。
ここまで気づくか?普通。
「俺はこんなミスしない」という自信のある人がいたら、
是非その根拠を教えて欲しいもんだ。

156 :貧乏紙:04/01/06 22:45
>>153
あの有名な「Internal Server Error」のこと?
すばらいじゃんあれさ。

157 :デフォルトの名無しさん:04/01/06 22:45
例外処理ってそんな面倒か。
複雑に考えすぎなんじゃないの。だって、想定する値じゃないときとかに、一行raiseって書いて、あと捕捉すればいいだけだぞ。
デバックが楽になるから、結果として早く書ける
Ruby使ってるけど、CGI書くのにも、便利。

158 :デフォルトの名無しさん:04/01/07 00:15
例外処理って適当に動かすプログラムになら便利だけど
業務では使いたくないな。レビューとか検証とかしんどそう

159 :デフォルトの名無しさん:04/01/07 12:31
適当な業務だな。

160 :デフォルトの名無しさん:04/01/07 20:55
>すばらいじゃんあれさ。
>すばらいじゃんあれさ。
>すばらいじゃんあれさ。

人類に分かる言葉で書いてくれ。

161 :デフォルトの名無しさん:04/01/08 03:18
>>160
誰に言ってんだよ。

162 :デフォルトの名無しさん:04/01/11 17:21
156 貧乏紙 New! 04/01/06 22:45
>>153
あの有名な「Internal Server Error」のこと?
すばらいじゃんあれさ。


163 :デフォルトの名無しさん:04/01/11 17:39
>>160-162
いや彼の仲間は、意外にたくさんいるぞ。

http://www.google.co.jp/search?hl=ja&ie=UTF-8&oe=UTF-8&c2coff=1&q=%E3%81%99%E3%81%B0%E3%82%89%E3%81%84&lr=

もしかしたら、俺たちが異端児なのかもしれない。

164 :デフォルトの名無しさん:04/01/12 14:53
【すばらい】
入力ミスから発生した言い回しのひとつ。「すばらしい」の最上級。

165 :デフォルトの名無しさん:04/01/18 19:03
豊富なバリエーション
すばらい
すばらいい
すばらいし
すばらいしい

166 :デフォルトの名無しさん:04/01/18 20:16
「すばらいいし」は無かったから、これを広めようか。

167 :デフォルトの名無しさん:04/01/18 20:17
すばいらし→1件

168 :デフォルトの名無しさん:04/01/18 20:48
すらばしい -> 160件


169 :デフォルトの名無しさん:04/01/25 11:56
意味がわかってるなら突っ込まなくてもいいだろ。
「今日はバグがすぱーすぱーでした」 とか言われて意味わかるか?
オレにはわからんが、後輩にはわかるらしい。女の脳みそは理解できん。

170 :デフォルトの名無しさん:04/01/25 11:58


171 :デフォルトの名無しさん:04/01/25 13:02
>>156
そりゃなにか違うような。
名前違わなかったか?

そういうことはTomcatやApacheなどサーバ側の設定の
問題だろ。

172 :デフォルトの名無しさん:04/01/25 15:34
>>169
>「今日はバグがすぱーすぱーでした」 とか言われて意味わかるか?
>オレにはわからんが、後輩にはわかるらしい。女の脳みそは理解できん。

それは結構最近のパラダイムだから、お前がまだ知らないのは許してやる。
しかし、新しい言葉を聴いたらすぐに自分で調べる癖をつけないと、
いつまでたっても恥をかき続けるぞ。
http://www.google.co.jp/search?q=%E3%81%99%E3%81%B1%E3%83%BC%E3%81%99%E3%81%B1%E3%83%BC&ie=UTF-8&oe=UTF-8&hl=ja&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=lang_ja


173 :デフォルトの名無しさん:04/01/25 16:28
くそ〜。検索しても分からねぇ。タバコとどう関係があるんだ。

174 :デフォルトの名無しさん:04/01/27 21:55
void Main(void){Main();}
void main(void){Main();}

175 :デフォルトの名無しさん:04/02/01 01:15
>>172
そんな言葉を知らないことを恥だと考えることの方が恥ずかしいんだけど。

176 :デフォルトの名無しさん:04/02/01 01:56
>>174
何がしたいのか知らんがこれで十分だろ
main(){main();}

177 :デフォルトの名無しさん:04/02/01 14:46
main() は、プログラムから呼び出してはならない。
main() のリンケージは、実装依存である。
main() のアドレスを使うことはできず、main() を inline や static と宣言してもならない。

■これは、プログラムとその環境の間のインターフェースの実装者に完全な裁量権を保証するためである。
■ゆえに、main() を関数として実装しないような実装を想像することさえできるであろう。

そんな実装が実在するかどうかは知らんけどね。

178 :デフォルトの名無しさん:04/02/01 14:52
一般的には、スタートアップが通常のmain()関数を呼び出す形式だからな。

179 :デフォルトの名無しさん:04/02/05 16:15
extern "C" char main[] = {0xc9};


180 :デフォルトの名無しさん:04/02/05 19:54
>>179
懐かしいな

181 :デフォルトの名無しさん:04/04/17 07:34
ハダカの対象

182 :デフォルトの名無しさん:04/04/17 10:55
>>181
死んだ。

183 :デフォルトの名無しさん:04/04/17 21:59
try{
throw(10);
}catch(int i){
throw(10);
}

184 :デフォルトの名無しさん:04/04/17 23:09
俺は例外が出ても例外由来とエラーの内容をコメントさせるだけで
対処しないヘタレ。アサートダイアログより親切か?程度の
Windowプログラマの戯言ですた。やってることはデバッグの
延長線上でしかなかったりする。
OSとかサーバとかなら何とかせにゃならんかもって気がするが。


185 :デフォルトの名無しさん:04/04/18 13:37
500

186 :デフォルトの名無しさん:04/04/18 23:25
>>153
それをいうなら
エラー出力をリダイレクトできないMS-DOSひいては95系列の
Windowsの設計ミス。

Javaはエラー出力をファイル等にリダイレクトする必要性から
しかたなくそういう仕様になった。(Windows版だけだったかもしれん)

187 :デフォルトの名無しさん:04/04/28 12:09
鼻毛

188 :デフォルトの名無しさん:04/04/28 12:19
>>186
WindowsのせいでJavaはかような糞言語になったという主張だね?

189 :デフォルトの名無しさん:04/04/28 12:22
裸のジェネラル

190 :デフォルトの名無しさん:04/04/28 12:38
ボボボーボ・ボクは例外処理が嫌いなんだな

191 :デフォルトの名無しさん:04/04/28 17:27
catchし忘れの例外がthrowされてたら、
必ず警告なりエラーなり出すようにすれば?
コンパイラがさ。

192 :デフォルトの名無しさん:04/04/28 17:29
↑あ、ごめん対策済みでしたか。失礼しました。

193 :デフォルトの名無しさん:04/04/29 17:11
ボボボーボ・ボーボボクは例外処理が き 嫌い いいいいいいいいいいいいいい いいいいいいいいいいいいいいいいいいな なななななんだな なな

194 :デフォルトの名無しさん:04/04/29 22:05
野に咲く〜 花のよ〜うに〜

195 :デフォルトの名無しさん:04/04/29 22:08
鼻毛真拳

196 :デフォルトの名無しさん:04/04/29 22:14
ボゲー!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

197 :デフォルトの名無しさん:04/04/29 22:32
>>36
実際、何を勘違いしているのか、例外を正常な動作の分岐用フラグのつもりで
使うというやつがいて困ったことがあるなぁ

「例外」とかかっこつけてオブラートに包んだ表現しないで
素直に「エラー」と呼ぶようにすれば多少意識が変わるのではないかと思う。

DOSのBATだとERRORLEVELで分岐するのが通常だがな。

198 :デフォルトの名無しさん:04/04/29 23:49
ところで、JavaでもGenericsを使い出すと投げられる例外を
事前に決めておくのが辛くなってくると思うんだが、
その辺の対策は無し?

199 :デフォルトの名無しさん:04/04/30 15:04
〜 ←鼻毛

200 :デフォルトの名無しさん:04/05/02 16:37
〜 ←尻毛

201 :おそれす:04/05/02 16:52
>>198
JavaのGenericsでは、throwする例外の型が変わるはずないと思うが。

202 :デフォルトの名無しさん:04/05/02 20:09
>>201

public class HogeException<T> extends Exception {}
があったときに
try {
} catch (HogeException<Foo> e) {
}
とかできないって話だろ?

203 :デフォルトの名無しさん:04/05/11 04:33
ボボボーボ・ボク

204 :デフォルトの名無しさん:04/05/11 05:30
>>202
それをやるなら、独自のExceptionを作れと。
JavaのGenericsはコンパイル時型チェックの仕組みだしな。

205 :デフォルトの名無しさん:04/05/11 09:12
>>1
使えない奴はあんたみたいに大抵例外放置してるよ。
RuntimeExceptionは完全無視、
後は大体catch( Exception e ) {}で放置。
エラー起きて発生箇所特定するのにハァハァ必死な顔してるよ。

206 :デフォルトの名無しさん:04/05/11 14:22
>>197
CLUはend of fileを例外で処理する仕様のライブラリでした。
End of listはどうだったかなあ?

207 :デフォルトの名無しさん:04/05/12 14:40
スレタイのボーボボとは?

208 :デフォルトの名無しさん:04/05/12 16:26
>>207
スレタイは、ボーボボの部分が入れ替わってると思うが。

209 :デフォルトの名無しさん:04/05/14 11:30
>>207-208
正直、意味が分からん。

210 :デフォルトの名無しさん:04/05/14 11:42
>>209
そのくらいぐぐれよ( ̄ー ̄)
ttp://www.tv-asahi.co.jp/bo-bobo/

211 :デフォルトの名無しさん:04/05/14 13:25
>>210
正直、意味が分からん。

212 :デフォルトの名無しさん:04/05/14 14:45
ヽ( ・∀・)ノ ウンコー

213 :デフォルトの名無しさん:04/05/14 14:49
なんでも首突っ込むじじい

214 :デフォルトの名無しさん:04/05/14 15:05
>>211
意味のわからなさだけがウリのマンガだからな。

215 :デフォルトの名無しさん:04/06/03 14:28
例外処理は、それなりの分散処理や大規模なプロジェクトにこそ必要。
なのにC++の場合は、コンパイラの例外処理に対する仕様が統一されてないのはなんともな。

bccでは可能なthrowの再投入がgccでは出来なかったり、
例外呼び出したことが原因で止まったりとか頭痛い。


216 :デフォルトの名無しさん:04/06/03 16:15
>>215
お前がコンパイラとデバッガの使い方を知らないだけ。

217 :デフォルトの名無しさん:04/06/03 16:48
>>216
それを言われると辛いな。

んで、調べたんだけど分からないんですが、
gcc(g++)で、例外の再投入時のコアダンプ出しての終了を止めさせる方法と。
VC付属のコンパイラで、関数の例外指定可能にする方法教えてください。
後者の方は調べた先では無理みたいな英文が載ってたんですが、
隠しオプションか何かあるんですか?


218 :217:04/06/03 16:53
>関数の例外指定
じゃなくて、関数の例外型指定でした。


219 :あいタン ◆3QC.t4i5w6 :04/06/03 17:19
ぬるぽだね!

( ノ ̄∇ ̄)ノ みんなーーーーーーー、あいでーーす!!( ̄ー ̄)ニヤリッ
またーーーーり


220 :デフォルトの名無しさん:04/06/03 23:39
>>217
> gcc(g++)で、例外の再投入時のコアダンプ出しての終了を止めさせる方法と。

例外を再投入してコアダンプ出して終了するソースをみせてくれませんか?

221 :デフォルトの名無しさん:04/06/04 01:15
#include <iostream.h>

main( )
{
try
{
try
{
throw "トライ";
}
catch ( ... )
{
cout << "全ての例外を捕まえた" << endl;
throw;
}
}
catch ( char *s )
{
cout << "メッセージ: " << s << endl;
}
}

これなんですけど、bcc32では問題ないんですが、
g++だと再投入時に停止するんですよね。

222 :デフォルトの名無しさん:04/06/04 01:36
>>221
"トライ"は char const* だから、 catch( char* ) にはマッチしない。
マッチするハンドラが見つからないからabort()逝きで正しい。
キャッチしてしまうbccがクソ。

223 :デフォルトの名無しさん:04/06/04 01:43
文字列リテラルは互換性のためchar*だけど?

224 :デフォルトの名無しさん:04/06/04 01:46
きゃは、bccの糞さ加減が露呈(プゲラ

225 :デフォルトの名無しさん:04/06/04 01:46
>>222
なるほど、そういうことでしたか。
成功しました、どうもありがとうございます。

しかし、これbcc厳しいですね。
const char *もchar *両方マッチングしてしまうんですね。

226 :デフォルトの名無しさん:04/06/04 07:03
>>223
throwに文字列リテラルを書いた場合はその変換は起こらないことが明記されているようだ。
FDISの 15.1 -3- に記述がある。

227 :デフォルトの名無しさん:04/06/06 02:17
>>186
よくわからないけど、stderrの話?

228 :デフォルトの名無しさん:04/06/07 03:15
鼻毛真拳の話

229 :デフォルトの名無しさん:04/06/15 11:37
鼻毛真拳の話

230 :デフォルトの名無しさん:04/06/15 14:06
ところてんの話。

231 :デフォルトの名無しさん:04/06/23 12:38
operation;
if (failed) {
 rollback;
}

よりも

operation
if (failed) {
 throw;
}
....
catch() {
 rollback;
}

の方がどう考えても見苦しいんですが、
フレームワークの方で例外を投げてくれない場合も自分で例外投げるのって普通なんですか?

232 :デフォルトの名無しさん:04/06/23 12:40
...
の部分で失敗する要因がないなら自分で投げるのはアホだな。
あるならありかもね。

233 :デフォルトの名無しさん:04/07/03 03:42
>>231
C用のフレームワークをラップするときは普通でしょ。
返り値エラーから例外への変換ね。


234 :デフォルトの名無しさん:04/07/08 20:54
http://www.atmarkit.co.jp/fjava/javatips/005eclipse002.html
 @IT > Java Solution > Java TIPS > すべての例外クラスを捕捉する
 Eclipse活用編
Eclipseですべての例外クラスを捕捉する

こういう機能があると例外を積極的に試用することも惜しまなくなる。

235 :デフォルトの名無しさん:04/07/08 20:58
>>234
printStackTraceだけかよ。
まったく、いやな例外処理だな。
それじゃ例外おきてもログ吐くだけでそのまま処理がすすむつーの。
無い方がマシ。


236 :デフォルトの名無しさん:04/07/08 21:00
IDEでTODOを自動生成したりそれを一覧表示する機能はMSの特許に抵触するな。
Eclipseからは送球に削除した方がいい。

237 :デフォルトの名無しさん:04/07/08 21:42
IDEに組み込まれたTODOってDelphiの昔から存在するような気がするが

238 :デフォルトの名無しさん:04/07/08 21:48
BorlandはMSとクロスライセンス契約を結んでるから無問題

http://japan.cnet.com/news/ent/story/0,2000047623,20069128,00.htm

239 :デフォルトの名無しさん:04/07/09 19:33
申請前から広く使われていた周知の技術って、無効じゃないか?

240 :デフォルトの名無しさん:04/07/09 20:03
そう思うならそう申請するしかない

241 :デフォルトの名無しさん:04/07/09 23:09
>>239
そうです。
日本の特許庁の立場は、それは裁判所の扱う問題で、
特許庁は、初めての申請であればそれを受理する、というものです。



242 :デフォルトの名無しさん:04/07/10 08:55
>>236
Eclipse3.0ではそのと挙問題を見事に解決しているぞ。
もうひとつ種類の異なるウィンドウに表示されるようになることで
解決したんだから無問題

243 :デフォルトの名無しさん:04/07/10 08:56
>>235
それだったらCode Templatesを自作してしまえばいい。
コードアシスト機能でもパターンを追加すると楽だ。

それと、Jakarta Velocityも使え。

EclipseのVelicity UIプラグイン、 Simteecプラグインを使うと楽だ。

244 :デフォルトの名無しさん:04/07/10 08:58
>>241
JavaScriptのポップアップ特許を思い出したよ。
無効になったけどなw

245 :デフォルトの名無しさん:04/07/10 11:53
例外って関数外へのthrowを禁止した方が
使える気がする。

246 :デフォルトの名無しさん:04/07/10 11:55
頼むからネタだといって

247 :デフォルトの名無しさん:04/07/10 11:58
予言しよう!
>245は次に、例外使った処理ジャンプを「発明」する!

248 :デフォルトの名無しさん:04/07/10 12:13
自分の経験からすると、一般のアプリケーションレベルのコードでは
そこが源流となる例外を放つケースは無いと断言出来る。
例外は全てその下のレイヤー(APIとか標準ライブラリ)から飛んでくる。
そして、それらの例外は復旧不能なものが殆どで、例外が起きた時点でアボーンが常。
だったら、自分の書くコードでは関数外例外は禁止した方が
書くコード量が減って見やすくなっていいんじゃないかにゃ〜ん

249 :デフォルトの名無しさん:04/07/10 12:13
関数外へ飛び出すのを禁じた例外か・・・
ちょっと欲しい

250 :デフォルトの名無しさん:04/07/10 12:16
>>248-249
ドカタ作業ばっかやってると偏るぞ……
例外もいちど復習してこいや

251 :デフォルトの名無しさん:04/07/10 13:09
お前の書くコードは、エントリから終わりまで1関数なのか?
いくらドカタでも、そんなコードばっかり書いてると首になるぞ?

252 :デフォルトの名無しさん:04/07/10 15:13
>>248
ムダな経験だたネ

253 :デフォルトの名無しさん:04/07/10 16:18
スレタイからして糞スレかと思ったら、意外に良スレでワロタ

254 :デフォルトの名無しさん:04/07/12 09:47
>>248
同意
アプリケーションレベルのオブジェクト間通信って関数呼び出しだけに
マッピングするとは限らんので、エラー通知の汎用的な解として
例外はいまいちしっくりこない。
全部例外安全にするのもコスト(コード的にも、実行時的にも)がかかりすぎるし、
そうでない場合は、関数呼び出し順序等に強い依存関係が生まれそうでこわい。

255 :デフォルトの名無しさん:04/07/12 10:24
>>248>>254
まとめて逝って良し

プログラマの裁量範囲でうまく使え


256 :デフォルトの名無しさん:04/07/12 10:30
>>255
裁量範囲で例外は使いません。

257 :デフォルトの名無しさん:04/07/12 10:56
>>256
裁量って何か知ってるか?

258 :デフォルトの名無しさん:04/07/12 11:19
>>254
> 全部例外安全にするのもコスト(コード的にも、実行時的にも)がかかりすぎるし、

同じことを、

result1 = func1(arg11, ...);
if (result == -1) {
// ああした
}
result2 = func2(arg21, ...);
if (result2 == -1) {
// こうした
}

でやるより簡単だから、例外が最近の言語にはあるんだが。
callerで処理すれば済めば簡単なんだが、
callerのcallerのcallerで処理しないと行けない場合大変だ。

実際qmailのコードをみるとほとんどがエラー処理だ。
機能をprocessに分割しているserverでもまじめに書くとああなる。



259 :デフォルトの名無しさん:04/07/12 13:00
まぁ趣味でやってる人は例外使わなくてもいいんじゃないの?



260 :デフォルトの名無しさん:04/07/12 14:20
言葉が足りなかった。私が言いたいのは強い例外安全
(呼び出し前と例外発生後で状態の変化がない事)の事です。

>>258
func1の実装とそれを呼び出している実装の関係が汎用ライブラリのコードと
アプリケーションコードの関係だってんなら同意するけど。
コンテキストを多く持つAppレベルのオブジェクトの場合、強い例外安全を
各メソッドで実現するコストが高すぎるってのが、私の感覚。
勿論、全メソッドで強い例外安全を確保して再利用性を高めうようって発想も
わかるけど、そもそも、Appレベルのコードって再利用する事自体少ないし。
ライブラリってんなら話は別だけど。

261 :254=260:04/07/12 14:23
ageてしまった。sry

262 :デフォルトの名無しさん:04/07/12 15:44
>>258
まあ>>258のコードは冗長だけど
見通しは良いわな。

try{
func1(...);
func2(...);
func3(...);
func4(...);}
catch( exception1 e){ ...}
catch( exception2 e){ ...}
catch( exception3 e){ ...}
catch( exception4 e){ ...}

これでは、すっきりしているが相関がわからない。
そこいら辺の情報がスッポリ抜け落ちているからな。

また、どの関数がどの例外を投げる可能性があるのか
わからせる為に、列記しなきゃならないってとこ
はっきり言ってダルいっしょ。IDEのサポート無しじゃ書いてられないよ。
現にSTLportとか守ってないしな、駄目じゃん標準ライブラリが守らないんじゃw
まー、こーいうとこはまだ改善の余地ありとか思う。

263 :デフォルトの名無しさん:04/07/12 17:12
そういうときこそ

public void finc1() {
 try{

 } catch (Exception1 e){ ... }
  catch (Exception e){ ... }
}
とメソッド内に納めると思うのだが。


264 :デフォルトの名無しさん:04/07/12 17:14
あとは、例外クラスを自作するとかな。
Exceptionクラスを継承してな。

public class Exception1 extends Exception {
 public Exception(){
  super("original exception message.");
 }
 public Exception1(String message){
  super(message);
 }
}
みたいにな。


265 :デフォルトの名無しさん:04/07/12 17:18
キャッチした例外をため込みテクニックもある。

import java.util.ArrayList;

//略

 private ArrayList exceptionArray;
public void finc1() {
 try{

 } catch (Exception1 e){
  exceptionArray.add(e);
  e.printStackTrace();
 }
  catch (Exception e){
  exceptionArray.add(e);
  e.printStackTrace();
 }
}
こうやって例外をキャッチするたびにArrayListに例外オブジェクトを蓄積してゆく。
そうすると例外情報が上書きによって隠蔽されることもなく、
欲しい例外情報を確実にはき出してくれる。

266 :デフォルトの名無しさん:04/07/12 18:03
しかし例外というのも考えると難しいよ。
例えばゼロ除算だが、これの例外処理って必要だろうか?
例外として起こりうる可能性がある以上設けるべきだろうか、
しかし、そもそもまともなコードを書いていればゼロ除算など
ありえない訳で。
ありえないならそもそも例外なんて考えなくていいんじゃないか
みたいな。

また例外というか、コンピュータにおけるエラーって極端に言えば
1、ハードの障害によるもの
2、オペレーターの入力ミスによるもの
この2点しかありえない訳じゃん。(バグを除く)
だったら、この2点だけ対象とした特例的処置を設ければ
それ以外の部分ででエラーというものを意識する必要なんて
別段ない気がするんだよね。

267 :デフォルトの名無しさん:04/07/12 18:35
>>266
ゼロ除算はJavaなら無問題だが。
では新たにそういうものを実装するにはどうすればいいか?
RuntimeExceptionクラスを継承するが
それをなにかしらクラスに組み込まないといけない。


268 :デフォルトの名無しさん:04/07/12 18:36
データのvalidationをする部分と
データの実処理をする部分を
分けて作ればいいじゃん。

だいたい二度手間になるけど。

269 :デフォルトの名無しさん:04/07/12 18:38
>>266
その二点だけじゃないんだよ。
リリースされて顧客が実際に使ってみて
初めて解るような潜在的バグというものが隠れている。
顧客に気づかれる前にこちらで処理するにはテストケースを
作るのだが。例外があるなら例外を積極的に優先的に使った方がいい。

キャッチされるかも知れない例外はすべてとらえておくべき。




270 :デフォルトの名無しさん:04/07/12 23:14
おまいら、例外投げまくるライブラリは作るの楽ですよ。(たぶん)

271 :デフォルトの名無しさん:04/07/12 23:22
>>262
それ大雑把すぎじゃないの
>>258の例で言えば
try{ func1(); } catch(exeption1 &e) {};
try{ func2(); } catch(exeption2 &e) {};
try{ func3(); } catch(exeption3 &e) {};
try{ func4(); } catch(exeption4 &e) {};
と書けばいいだけで。

>>265
C#ではInnerExceptionって親例外を参照するプロパティがあるので
ArrayListに格納しなくても連鎖的に保持できるよ。


272 :デフォルトの名無しさん:04/07/12 23:43
>241
亀レスだが嘘書くな。特許の三つの条件言ってみろよ

273 :デフォルトの名無しさん:04/07/13 01:09
>>271
func1がexeption1「しか」throwしないなら、ね。
func1〜4それぞれがexeption1〜4の全てをthrowし得るならどうする?

274 :デフォルトの名無しさん:04/07/13 01:23
>>266
Connection refused


275 :デフォルトの名無しさん:04/07/13 09:14
>>271
C#ではJavaにあるthrows宣言が存在しない対策をどうとっているのか是非とも教えて遅れ。

276 :デフォルトの名無しさん:04/07/13 10:09
>>275
throwsに対応する機能はないよ。ノーガード。
throwsネタは21世紀における新宗教論争だからここでは意見してあげないw

C#作者の考えはこんなかんじ
http://www.artima.com/intv/handcuffsP.html

277 :デフォルトの名無しさん:04/07/13 16:34
>>266
> 例えばゼロ除算だが、これの例外処理って必要だろうか?
必要に決まってんじゃん。
たとえばその例外発生元がプラグインだった場合、
プラグインだけを切り離さなければならない。
全部落ちる必要はないし、その程度でメインのプログラムが落ちたらマヌケだろ。
プラグインじゃなくても、ゼロ除算により「その機能」が
使えないだけで他に影響ない部分もある。

他にも例外発生を分かりやすくするためにログに出力したり、メールで送信する場合も有る。
例外発生してそのまま処理を進ませられない場合でも、例外の処理をすることはある。

ただ、例外を処理するのはいいが、ログに出力しただけで、
例外が発生してない場合と同じ処理を続行するなんてコードを書かないこと。
たとえば>>234のEclipseの自動生成されたtry/catchブロックのようなもの。

例外の基本は上位の関数へ、そのまま/後処理をして/例外の種類を変えて throw。
スタックの最後の部分で例外処理。途中でもみ消したい場合のみ途中で処理。

278 :デフォルトの名無しさん:04/07/13 16:47
>>277
>ただ、例外を処理するのはいいが、ログに出力しただけで、
>例外が発生してない場合と同じ処理を続行するなんてコードを書かないこと。
理由を聞きたい

279 :デフォルトの名無しさん:04/07/13 16:57
>>277
まずゼロ除算というのはバグでしか発生しないよね。
そうするとつまり例外機構とは、バグが発生元なる例外も対象としていると考えて良いの?
自分としては、本来は含まれない、含まれないことが望ましいバグというものの為に
リソースを割り振るというのが、なんか引っかかるんだよね。
リリースビルドに、assertマクロをそのまんま残している感じで釈然としない

280 :デフォルトの名無しさん:04/07/13 21:42
例外派は、除算する前にゼロチェックしないの?

281 :デフォルトの名無しさん:04/07/13 23:15
0割するような入力してきたやつに対して、
関数側はどう返事したらいいんだ?
例外か返り値で返すしかないだろ。

返り値をエラー識別子なんぞに使いたくないから、
例外を返すんだ。わかる?

なんでゼロ割の話を特化させてるんだ?
ゼロ割を回避できるロジックが別にあるなら回避して、
無いなら例外だすだろ。普通は。

282 :デフォルトの名無しさん:04/07/14 01:52
除算する前にゼロチェックって…

もしかして<fenv.h>すら知らない人?
C++の例外うんぬん以前に、レベル低すぎて話にならない。
http://www.opengroup.org/onlinepubs/009695399/basedefs/fenv.h.html

まあ除算する前にゼロチェックが有効な局面もあるけどね。
と馬鹿な反応をされないように書いておくよ。(これが例外処理)

283 :デフォルトの名無しさん:04/07/14 09:12
>>276
C#はバグを減らすことよりも利便性を重視したからthrowsをはずしたんだと思っている。

284 :デフォルトの名無しさん:04/07/14 23:06
>>283
リンク先読んだか?そんなこと言ってないよ。

285 :デフォルトの名無しさん:04/07/15 00:57
彼が本当のことを言うと思うかい。
彼が本当のことを言わないのはほとんどが
お金のためなんだよ


286 :ぽろじょあ ◆niBmDfC40k :04/07/15 01:01
( .3.) ボボボーボ・ボクは例外処理が嫌いなんだなNA

287 :デフォルトの名無しさん:04/07/15 01:12
( .3.) ボボボーボ・ボクは例外処理が嫌いなんだなNaN

288 :ぽろじょあ ◆niBmDfC40k :04/07/16 02:18
( .3.) ボボボーボ・ボクは2ちゃんねるの人気者だYO
       ぽろじょあ#ぽろっぽ

289 :デフォルトの名無しさん:04/07/16 11:53
ほら、>>282 が空気読まないで書くから、変なのが来ちゃったじゃないか。

290 :286:04/07/16 13:52
別のスレに居るのを真似して>>286書いたけど、
>>287>>288は俺じゃないよ

291 :NaN(>>282=>>287):04/07/17 00:19
すまんな。

292 :デフォルトの名無しさん:04/07/17 01:04
     もそもそ
        ,、ッ.ィ,  
      ,:'゙    '; 
    (( ミ,;:.   ,ッ )))
       ゙"'''''"゙
   もふっ
       ハ,_,ハ
      ,:' ´∀` ';
      ミ,;:.   ,ッ  ノノ
       ゙"'''''"゙
   ポィン 
       ハ,_,ハ  ポィン
      ,: ´∀` ';
      ミ,;:.   ,ッ
       ゙"'''''"゙ 
      ヽ  ili / 
     -      -

           スタッ
       ハ,_,ハ,
      n' ´∀`,n,
      ミ,;:.   ,ッ
       `'u゛-u'

            ズビシッ
       ハ,_,ハ
      ,:' ´∀`';9m <age!
      ミ,;.っ ,,ッ
      ι''"゙''u

293 :ぽろじょあ ◆niBmDfC40k :04/07/17 01:29
( .3.) ボボボーボ・ボクは例外処理が嫌いなんだなNaN

294 :ぽろじょあ ◆niBmDfC40k :04/07/17 01:40
( .3.) ボボボボーボ・ボクは例外処理が嫌いなんだなNaN

295 :デフォルトの名無しさん:04/07/17 02:19
いやつまんねぇから

296 :デフォルトの名無しさん:04/07/20 13:34
こいつを使えば例外処理もかなり楽になるでえ。
いちいちVectorに例外をため込む必要がなくなるで。

org.apache.commons.lang.exception.NestableException
http://www.jajakarta.org/commons/lang-2.0/ja/withoutPrimary/org/apache/commons/lang/exception/NestableException.html

org.apache.commons.lang.exception.NestableRuntimeException
http://www.jajakarta.org/commons/lang-2.0/ja/withoutPrimary/org/apache/commons/lang/exception/NestableRuntimeException.html

297 :デフォルトの名無しさん:04/08/04 17:38
例外処理が嫌いな皆さんへ。

C++スレで536が叩かれてます。助けに行ってあげてください。
http://pc5.2ch.net/test/read.cgi/tech/1090180012/536-

298 :デフォルトの名無しさん:04/08/04 17:39
>>297
期待通りの動きだ。

299 :ぽろじょあ ◆niBmDfC40k :04/08/23 23:16
( .3.) ボボボーボ・ボクは例外処理が嫌いなんだなNaN

300 :デフォルトの名無しさん:04/08/24 01:21
C++では例外処理なんて不要。男は黙って戻り値確認

301 :デフォルトの名無しさん:04/08/24 21:16
C++では戻り値確認なんて不要。男は黙って例外処理。

302 :デフォルトの名無しさん:04/08/25 23:03
C++なんて不要。男は黙ってろ

303 :デフォルトの名無しさん:04/08/31 11:31
>>297
>>563>>536とを間違えているだろ?
間違いを見つけるのに苦労したぞ。
まったく、最近こうレス番号を間違える奴が多すぎてウザイ

304 :デフォルトの名無しさん:04/08/31 23:12
亀レスしときながら最近とか言うな

305 :デフォルトの名無しさん:04/09/01 20:30
昔やったプロジェクトでさ、スレッド起動するクラスがあって、
そっから例外が飛んでくるとクラッシュしたりして大変だったね。
最初何が原因かわからなくてさ。
おかげで障害票てんこ盛り。
スレッド頭でキャッチしとけってーの。
スレッド越しの例外投げって危険極まりないね。

306 :デフォルトの名無しさん:04/09/01 20:35
調べたら某ミドルウェアのライブラリが例外投げてんだよね。
勝手に起動したスレッド上で。
全然異常系テストしてねーなってことが判った。
結局そのライブラリは欠陥持ちだってことで、どうしようもないから
ミドルウェアのソース貰って修正したさ。
アホらし。


307 :デフォルトの名無しさん:04/09/01 20:37
それは例外には責任無いだろw

308 :デフォルトの名無しさん:04/09/01 20:45
>>307
俺が言いたいのは
例外とスレッドは相性悪いってことだよ。
C++は言語仕様で保障されてないからそれ以後怖くてな、
ミドルウェアの解析までやらされたんだぜ?
例外の仕様がこんなんじゃやってられねーよ。
クソコード書いたミドルウェアのアホ(逃げた)が一番悪いんだが、
不慣れで例外使われるより値返された方がマシだろ。

309 :デフォルトの名無しさん:04/09/01 20:52
例外を投げるのはいいさ。
だけどな、任意の箇所で捕捉できなきゃただの爆弾だよ。
スレッドまたいだだけでクラッシュするのは頭悪いとしか言い様がない。
今回みたいな欠陥ライブラリは、外からじゃどうしようもないだろ。
ソースが参照できたからよかったものの、
無かったらプロジェクト消滅してたぜ?


310 :デフォルトの名無しさん:04/09/01 20:58
例外を処理できる位置で捕らえないで、文句言ってるってことですか?
返された値をチェックしないでスレッドまたぐのとどう違うんですか?

311 :デフォルトの名無しさん:04/09/01 21:00
↑おまえ、ミドルウェアのアホ並の思考回路だな。

312 :デフォルトの名無しさん:04/09/01 21:04
例外に責任無いじゃん。

313 :デフォルトの名無しさん:04/09/01 21:05
無いよね?

314 :デフォルトの名無しさん:04/09/01 21:07
例外処理大好きな俺は orz

315 :デフォルトの名無しさん:04/09/01 21:09
俺なんか一日に3回は例外投げてるけどね。

316 :デフォルトの名無しさん:04/09/01 21:18
>>309
あのライブラリね。
俺もはまったことあるよ。
try・・・catchって書けば普通に動くようになるよ。

317 :デフォルトの名無しさん:04/09/01 21:24
ここのが相応しくないか?

バグ対策とバカ対策
http://pc5.2ch.net/test/read.cgi/tech/1067106300/

318 :デフォルトの名無しさん:04/09/01 22:06
例外はちゃんとキャッチしろよ

319 :デフォルトの名無しさん:04/09/01 23:05
↓例外

320 :デフォルトの名無しさん:04/09/01 23:15
│    _、 _
│  ヽ( д` ; )ノ
│ へノ   /
└→ ω ノ
       >


321 :デフォルトの名無しさん:04/09/02 00:30
|   ∧_∧
|  ( *´Д`)
|  人 ヽノ、
└―(  ヽ_つ,,,つ
プスッ )  ))
   (__))

322 :デフォルトの名無しさん:04/09/02 03:42
>>308>>309
例外だからこそ、すぐに問題が発見されたのであって、
エラー原因を返り値で渡し損なっている、
って問題ならもっと発見しにくかったはず。

>>305>>306までの愚痴はまあ分かる。

323 :デフォルトの名無しさん:04/09/02 19:49
ただのよくあるタイプのバグの一つだろ

324 :デフォルトの名無しさん:04/09/04 00:06
>>305
ちゃんとロギングしろよ。
今ならアスペクト指向プログラミングによって
さらにロギングが楽になったぞ。


325 :デフォルトの名無しさん:04/09/04 04:19
>>324
得体の知れない処理系なんか仕事で使えるかっての


326 :デフォルトの名無しさん:04/09/05 11:28
>>325
処理系というほどのものじゃないだろ。
JBoss
Spring
Seasar
など、盛りだくさん。
勝手に選べ。
いまならDIというオマケつき。

327 :デフォルトの名無しさん:04/09/05 11:51
>>326
世の中には「自社開発でない=得体の知れない、使えない」っつー思考する所がゴマンとあるのさ・・・

328 :デフォルトの名無しさん:04/09/05 13:01
きっと規模が大きいだろうに、AOPの実装もできないのか?

329 :デフォルトの名無しさん:04/10/30 03:56:47
ほほほほほほほほほほ保守

330 :デフォルトの名無しさん:04/11/07 23:16:04
「ボボ」は一部の地域では放送禁止。

331 :デフォルトの名無しさん:04/11/22 21:05:52
>>330
どこ?

332 :デフォルトの名無しさん:04/11/22 23:36:08
>>331
気になるんなら、検索するか
日本全国の女性と付き合って「ボボ!」って
叫んでみて、ひっぱたかれたらそこだッ!

333 :デフォルトの名無しさん:04/11/24 01:13:00
>>96
newの再配置構文を知らないみたいね。realloc的なものが
ないわけないでしょ。

334 :デフォルトの名無しさん:04/11/24 02:37:57
一年前のレスに向かって語りかける気分はどうだい?

335 :デフォルトの名無しさん:04/11/24 08:53:07
placement newはreallocとはぜんぜん違う気が

336 :デフォルトの名無しさん:04/12/29 16:39:42
>>324
アスペクト嗜好の資料を読んで
ログに使えると思った奴は素人

337 :デフォルトの名無しさん:04/12/29 16:48:59
}catch(...){

これでcatch all

338 :デフォルトの名無しさん:04/12/29 16:57:16
}
catch(Throwable e){
//>>1-337

}

339 :デフォルトの名無しさん:04/12/29 17:12:32
頼むからさぁ、Effective JavaやMore Effective C++の例外処理の項とか
Exceptional C++とかぐらい読んでくれないかなあ。

340 :デフォルトの名無しさん:04/12/29 17:16:11
強制させるならその本買ってきてよ

341 :デフォルトの名無しさん:04/12/29 17:16:58
Effective VB.NETがでたら読みます

342 :デフォルトの名無しさん:04/12/29 17:18:02
批判するならするだけの前提知識を持ってからにしろよと言ってるんだ。

343 :デフォルトの名無しさん:04/12/29 17:20:11
むしろこれらはC++やJava使うなら最低限の必読書だと思うが

344 :デフォルトの名無しさん:04/12/29 17:44:48
.NETの例外関係の設計はどうなの?

longhornは例外処理を持つ言語でAPIを全て設計し直しだから、
ちょっと期待しているんだけど。

ただ、MSは基本部分のエンジニアは優秀な人をお金出して呼んでいるけど、
周辺や実装部隊はイマイチだから、とんでも例外設計の可能性もあるなあ。


345 :デフォルトの名無しさん:04/12/29 18:25:06
↓待ってましたとばかりにthrows厨登場

346 :344:04/12/29 18:50:07
↑おい、出鼻くじくなよ(w

347 :デフォルトの名無しさん:04/12/29 19:05:51
>>344
例外キャッチしなくてもコンパイルとおるんじゃないか?
あんまいい作りとは思えんが

348 :デフォルトの名無しさん:04/12/29 19:19:07
そりゃ言語の仕様でしょ。
APIの設計はどうなんだろうねえ。
MSDNをちらっと見てみたけど、概説はまだないね。

349 :デフォルトの名無しさん:04/12/29 21:43:16
>>347
ttp://msdn.microsoft.com/vcsharp/team/language/ask/exceptionspecs/default.aspx

350 :デフォルトの名無しさん:05/02/08 17:38:03
VB6で、例外が起きた場所をキャッチして
画面ポップアップMSGにだすことは可能ですか

351 :デフォルトの名無しさん:05/02/08 18:58:54
assertと例外の使い分けってどうしてる?


352 :デフォルトの名無しさん:05/02/08 19:24:35
ライブラリの仕様としてのチェック(引数の正当性やメソッドがコール可能かどうかなど)は例外
デバッグ中のチェックコードはassert

353 :デフォルトの名無しさん:05/02/08 23:50:24
例外の使い方わからない(´Д`)


bool OresamaFunc()
{
  try{
    if(hogehoge){
      return false; // Error
    }
    // いろんな処理・・・
  }catch(...){
    //なんか例外出たのでエラーとする
    return false
  }

  return true;
}

これじゃだめ?(´Д`)

354 :デフォルトの名無しさん:05/02/09 00:27:43
>>353
↓こっちのが幸せな気がしないかい?

void OresamaFunc()
{
  if(hogehoge){
    throw OresamaError;
  }
  // いろんな処理・・・
}

74 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)