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

他人が作ったクラスとかだと例外のキャッチし忘れ多過ぎ
何の例外が飛んでくるかわからないクラスなんて怖くて使えない

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

保守age

↓次スレたてろ

＞何の例外が飛んでくるかわからないクラスなんて怖くて使えない
取りあえずJavaとC++では対策が既に成されてる。

後だしじゃんけんしたくせにC#はいまだに対策がとられておらず

アホアンチはこなくていいよ。

対策ってどんなの？

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

>>7
メソッドに何が飛んでくる可能性があるか書いてあるだろが。

>>3
次スレです。
http://pc2.2ch.net/test/read.cgi/tech/1065535118/

C++の例外処理は遅い

>>10
頻繁に呼ぶもんじゃないし、いいんじゃないの。

>>10
例外とはめったに起こらないから例外なんだから遅くてもいいだろ

統合環境使えば可能性のある例外全部教えてくれるけど、
言語自体にも対策方法があるの？

例外が遅いから分岐にしているだけじゃないか？
本来は例外として分類されるべき処理はいくらでもありそうだが

>>14
そんなに速度が要求されるのに例外にされるべき処理って何?

例外処理を使うと処理の流れというか思考の流れが飛ぶので気持ち悪い

正常系と例外系で分けて考えられるから見通しが良くなると思うんだが。

例外の方が重要なのに。おまえらわかってない。

効率重視ならいきなりthrowより
goto先にまずまとめたりしない？

あ、VBのGotoErrorラベルみたいなやつね。
VBっていうと敬遠されるかもしれんけど（ｗ

副作用が主の手続きは返すべき値が無いので、
自然と正常系以外は全て例外扱いになるが。

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

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

>>20
途中スコープの外れるインスタンスのデストラクタを読んでくれたりかなり高機能ですけどね。

後、例外が構造化できるのがポイント。
VBのそれにはまねできないわけだ。

C++は文法的になんの例外投げるのかとか知ることができないのがつらいね。
一応、メンバ関数の宣言の後ろにthrowをつけれるけど、
あってもなくてもコンパイルできちゃうわけで。

>>25
付けてもVCはthrow() (例外を投げない宣言)以外は未実装警告だして
使えないしね・・。VC7.1のISO仕様残り2%のひとつだ。

C#でゲーム作っててさ、
オブジェクトの終了を通知するための手段として
例外を使ってるんだわさ。
で、例外を受け取った外側の処理でそのオブジェクトへの
参照を外すようにしてる。
こういう使い方ってしないほうがいいのかな・・・？

>>1
＞そもそも例外処理って大域ジャンプだろ
例外処理を勘違いしてそんな書き方するやつがいるだけだ

>>25
へーそうなのか、C++はコンパイルとおっちゃうのか
そりゃあわけわからんプログラマが前工程やるとわけわからんくなるわな

>>27
そういう例外の使用法は、よく悪い例として取り上げられています
C#は詳しくないけど、デストラクタってありましたよね？

>>30
デストラクタはありません。（ファイナライザはありますが…）
C#では基本的にＧＣがメモリの後処理をしてくれます。

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

例外人間

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

これは当たり前として。

>>33
わかりました。bool値を返すように変更します。

じゃあC++でlongjmpの真似事をするにはどうすればいいんだ

実際、何を勘違いしているのか、例外を正常な動作の分岐用フラグのつもりで
使うというやつがいて困ったことがあるなぁ

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

まあ、どこまでが正常処理でどこからが異常処理かと言うのは個人差があるからな。

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

名前が悪いんだよ
例外機構じゃなくて大域脱出機構にでもすればよかったんだよ。

>>13
この世に使っているすべてのプログラマが統合開発環境を使っているとは限らないので
そういうものに頼る手法は却下

例外処理を効率よく処理できるデザインパターンを教えれ。
またはそのサイトや書籍をおしえれ

無い

なんかあるだろ。
例外に特化した本でなくてもいい。
なにかおすすめがいい。
鉄則本や落とし穴本でもいい

そもそも例外機構とOOに関連性はない。
例外処理の手順について理解を深めろ。

ある処理を実行してる最中にその処理の続行が完全に不可能になった時、例外を
生成して開放が必要なオブジェクトを廃棄し処理を停止させてるけどだめ？

ところでJava以外で例外処理なんて使ってる人いるの？

>>40
例外とは関係ないけど，もしかしたら
"NullObject パターン" を挙げると喜ぶ？

あれは例外に適しているものだったのか？
投げるべき例外をしっかりとつかみちゃんと正しく例外が処理されるのか？

例外処理ってsignal(3C)がsigaction(2)でしょ。
Windowsは知らんのだが、言語で処理するのは
あまり好きくなれん

>>48
それは普通割り込みという

嫌い「なんだな」　← なんだこれ

>>50
裸の大将じゃないの?

>>50
一般常識に疎いということはオタクだろ、お前。

ボーボボの喋りに特徴ないとは言え、スレタイのわりに1の本文普通すぎ。

>>52
純粋に若いだけかも。何年前だよ、裸の大将って

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

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

mainでcatch(...)すれば無問題

結局throwsという実験的機能は失敗に終わったということでFA?

>>55
Javadocならthrows句で宣言した例外クラスを書き出してくれるよ。
>>57
ということにしたいのですね　:-)

>>46
喜べるとはいえない。。もしそれが逆ならギャグいわれたってそれだけでは現実には何も進展がない。

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

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

裸の隊商はボーボボよりマイナーになったか。

少なくともJavaに関して言えば例外は非常にうまく機能してるんじゃないの？
逆にC#の例外書かなくてもコンパイル通っちゃうのは不安でいけない。
って書くとまた荒れる元になるかな。

throws Exception相当だからね。

れれれれれれれれれれれれれれ例外！！
ああっ！！出ちゃう！！例外出ちゃいますぅぅぅぅぅぅ！！！！！！！

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

まるでお粗末君のれれれのおじさんみたいだ。

>>64
ニャロメとケムンパスはいたと思ったが・・・。

>>18
何言ってんですか？

>>65
おそまつにもいるよ。ほうきをもったやつだろ

>>59
メンバにList<Exception>を持つExceptionサブクラス作ったら？
printStackTrace()とかオーバーライドしといて、あとListへの
Iteratorを返すメソッド追加しとけば、そこそこ便利じゃないかね。

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

Listである必要はないだろ。
ひとつ上への参照さえもてれば連鎖的に保存しておけるんだから。

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

つーかC++って構文無茶苦茶汚いね。
何が
List<Exception>
だよ。
おまえらそれで満足か？

>>70
ええ、その後に数十回同じキャストを繰り返すよりは。

>>70
＞List<Exception>
充分、きれいですが。

White Spaceの美しさは半端じゃない

>72
馬鹿やろ
破綻してるだろうが。

List<List<Exception>>

これでもうだめぽ（ｹﾞﾗ

それ、コンパイルエラー。

List<List<Exception>　>

だと思われ。

>>75
だから>>74は破綻しているといっているのではなかろうか。

>>75
ほっとけよ、XXXX房は。
唯一C++のtemplateに勝てる所なんだから。
そっとしておいてやっれって。

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

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

>78
初歩で陥るとこだ罠

>>78
ルーティングの段階でロールバック。
ロールバックの必要な処理は型やメンバでフィルタリング。
try {
....
} catch (filter &e) {
rollback();
thorw;
}

>>78
お前のコードの中にfinallyってあるか？
無ければ独習シリーズでも読み直して出直せ。

つーか例外めんどくせい。俺のコードには
try {
　foo();
} catch(...) {
//何もなし
}
というコードばっかりだよ。

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

>>82の書くプログラムは正直使いたくないと思いました。

だっていちいち例外かけって言われるからこうするしか無いじゃん。

だいたい、雑誌とかもこんな風に書いてるしな。

>>78
＞自動的ににロールバックされるわけでもないし。

されたら迷惑

>>82
スタックトレース位吐けやボケ。

>>87
禿道。例外発生したらスタックトレース。
決り文句。常にこう書くべし↓

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

例外発生時にも処理が続行されるがｷﾆｼﾅｲ

>>87がスタートレックにみえた_|￣|○

>>82
くたばれ

>>81
finallyなんてねえよ。あったらコンパイルとおらんし(w

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

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

Java厨は氏んでいいよ。

漢なら確固たる信念を持って例外処理すべし。
try {
　foo();
} catch (...) {
　throw;
}
これで決まりではないか。

あー、C++なのか。
あれだけゴチャゴチャした言語仕様なのに、finallyが無いってのは
けっこうビックリだよな。
最近じゃVB.NETにすら付いたのに。

>>94
デストラクタで各オブジェクトに後始末させるからいいんじゃないの

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

>>78
だな。
出口や入り口は少なければ少ないほど理解しやすくいいと言われてるのに、
例外処理はそれに完全に逆行してる
少なくてもC++では流行る気配すらないな

>>97
>出口や入り口は少なければ少ないほど理解しやすくいいと言われてるのに
気のせいです。

>>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も出口は一つ。

関数型で書けよ。制御を終わらす意味でのreturnなんか無いぞ。

関数型には例外処理があんのか？

>>99
今度は、そんな goto だらけのプログラムは、理解しにくいと言われるだけだぞ。

>>102
空気読んでよく読め

>>96
reallocﾜﾗﾀ

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

例外嫌いなC++屋は、まぁこれでも読んで出直せや。
ttp://boost.cppll.jp/HEAD/more/generic_exception_safety.html

例外はスレッドと相性悪いんだよなあ・・
理をうまく実践できない

手続き型と例外は相性が悪い。

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

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

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

>>106
そうかい?
C++例外+pthread+UNIXなら相性悪いと思うけど、
例外+スレッド一般は特に問題ないだろ。Javaとかね。

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

>>107
ばかだなぁ。

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

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

あわわ・・

×とすれば手続き型と全く同じですよｗ
○とすれば例外を使わない場合と全く同じですよｗ

まさか関数全てを
try{ ... } catch(...){}
で囲むバカはおるまい。

>>112
b()だけでいいだろ。真馬鹿め。

107のような場合は例外ならfinallyを使えばいいしな。
例外は常に例外じゃない方法よりも便利。

例外って便利か？
そりゃ例外使っても良い作りのプログラムにしとけばいいけど
そうするための苦労に比べ実入りが少ない気がする。

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

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

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

別にfinallyがなくてもtryの外に書けばいいだけだろ。

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

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

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

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

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

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

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

>>118
僕ちゃんは何がどう大変になるんだい？

>>96
reallocﾜﾗﾀ
でもたしかreallocみたいなことをできるOOPLなかったっけ？

>>113
bだけでいいとか言い出すと、次はtryで囲む事自体忘れる奴が現れる
そうなると、従来のif文によるエラーチェックを忘れるよりタチが悪い

>>119
簡単なんで、例外処理、あれもこれもやりたくならないかい?

>>115
> しかし、C++にfinallyが無いのは悲惨だな
> RAIIへの配慮が足りないぞ
逆じゃないの？コンストラクタ・デストラクタでRAII
を簡単にサポートできるから、finally無くても
破綻しないじゃないの？

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

例外かくとき
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);
} とすべきかで迷う

何がやりたいんだか理解できないが、スタックトレース吐いて
同じ例外投げたいんだったらこれでいいだろ。

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

124は例外の前にポリモフィズムをまず勉強すべきだな

>>124,125
Java?

Polymorphism だからポリモルフィズムでもポリモフィズムでも
どっちでも読めるんですね。一瞬まよってしまった。

>>121
class foo {
private:
　void a(...);
　virtual void b(...);
　void c(...);
public:
　void bar(...);
};

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

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

>>129
Zyaaそもそもプロトタイプ宣言すんなよ。と。

>>130
・誤爆。
・単なる釣り。
・単なるアフォ。

どれなんだ ?

どーでもいいがこのスレタイはボボボーボ・ボーボボを意識しているのか？

/* どーでもいいなら一々聞かないこと */

catch(...)
{
cout << "でも聞きたい" << endl;
}

ShowMessage("教えてageない");

sine

.NETの例外は恐くて使えない

>125
お前リリース品にもprintStackTraceみたいなデバッグプリント入れてるバカだろ。

>>138
お前日本語読めない馬鹿だろ。
しかもageてるし。

ん？ あげるとﾊﾞｶ呼ばわりされるのか？

>>140
お前日本語読めない馬鹿だろ。

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

>>138
ん、なんだ、125って俺の書き込みじゃん。
ということはお前は124？

.NETの例外は何飛んでくるか分からない。
怖い。

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

>>144
なんか同意。VBとかK&R Cとか曖昧性のある言語って高コストっす。

>>91
boostにもfinally相当がないの？

>>146
テンプレートでどうにかなる問題なんですか？

>>138
フレームワークとして使うならException#printStackTrace()いれとかんと。

>>115

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

unwind-protect ?
LISPの話をしているのか？

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

うん

Javaのスタックトレースがデフォルトで標準出力に出るのは設計ミスだと思う。

>>151
・・・以上ロートルアボートコア吐き厨の寝言でした。

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

>>153
あの有名な「Internal Server Error」のこと？
すばらいじゃんあれさ。

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

例外処理って適当に動かすプログラムになら便利だけど
業務では使いたくないな。レビューとか検証とかしんどそう

適当な業務だな。

>すばらいじゃんあれさ。
>すばらいじゃんあれさ。
>すばらいじゃんあれさ。

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

>>160
誰に言ってんだよ。

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

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

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

【すばらい】
入力ミスから発生した言い回しのひとつ。「すばらしい」の最上級。

豊富なバリエーション
すばらい
すばらいい
すばらいし
すばらいしい

「すばらいいし」は無かったから、これを広めようか。

すばいらし→1件

すらばしい　-> 160件

意味がわかってるなら突っ込まなくてもいいだろ。
「今日はバグがすぱーすぱーでした」 とか言われて意味わかるか？
オレにはわからんが、後輩にはわかるらしい。女の脳みそは理解できん。

す

>>156
そりゃなにか違うような。
名前違わなかったか？

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

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

くそ〜。検索しても分からねぇ。タバコとどう関係があるんだ。

void Main(void){Main();}
void main(void){Main();}

>>172
そんな言葉を知らないことを恥だと考えることの方が恥ずかしいんだけど。

>>174
何がしたいのか知らんがこれで十分だろ
main(){main();}

main() は、プログラムから呼び出してはならない。
main() のリンケージは、実装依存である。
main() のアドレスを使うことはできず、main() を inline や static と宣言してもならない。

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

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

一般的には、スタートアップが通常のmain()関数を呼び出す形式だからな。

extern "C" char main[] = {0xc9};

>>179
懐かしいな

ハダカの対象

>>181
死んだ。

try{
throw(10);
}catch(int i){
throw(10);
}

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

500

>>153
それをいうなら
エラー出力をリダイレクトできないMS-DOSひいては95系列の
Windowsの設計ミス。

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

鼻毛

>>186
WindowsのせいでJavaはかような糞言語になったという主張だね？

裸のジェネラル

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

catchし忘れの例外がthrowされてたら、
必ず警告なりエラーなり出すようにすれば？
コンパイラがさ。

↑あ、ごめん対策済みでしたか。失礼しました。

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

野に咲く〜　花のよ〜うに〜

鼻毛真拳

ボゲー！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！！

>>36
実際、何を勘違いしているのか、例外を正常な動作の分岐用フラグのつもりで
使うというやつがいて困ったことがあるなぁ

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

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

ところで、JavaでもGenericsを使い出すと投げられる例外を
事前に決めておくのが辛くなってくると思うんだが、
その辺の対策は無し？

〜　←鼻毛

〜　←尻毛

>>198
JavaのGenericsでは、throwする例外の型が変わるはずないと思うが。

>>201

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

ボボボーボ・ボク

>>202
それをやるなら、独自のExceptionを作れと。
JavaのGenericsはコンパイル時型チェックの仕組みだしな。

>>1
使えない奴はあんたみたいに大抵例外放置してるよ。
RuntimeExceptionは完全無視、
後は大体catch( Exception e ) {}で放置。
エラー起きて発生箇所特定するのにハァハァ必死な顔してるよ。

>>197
CLUはend of fileを例外で処理する仕様のライブラリでした。
End of listはどうだったかなあ?

スレタイのボーボボとは？

>>207
スレタイは、ボーボボの部分が入れ替わってると思うが。

>>207-208
正直、意味が分からん。

>>209
そのくらいぐぐれよ(￣ー￣)
ttp://www.tv-asahi.co.jp/bo-bobo/

>>210
正直、意味が分からん。

ヽ( ・∀・)ﾉ ｳﾝｺｰ

なんでも首突っ込むじじい

>>211
意味のわからなさだけがウリのマンガだからな。

例外処理は、それなりの分散処理や大規模なプロジェクトにこそ必要。
なのにC++の場合は、コンパイラの例外処理に対する仕様が統一されてないのはなんともな。

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

>>215
お前がコンパイラとデバッガの使い方を知らないだけ。

>>216
それを言われると辛いな。

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

>関数の例外指定
じゃなくて、関数の例外型指定でした。

ぬるぽだね!

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

>>217
> gcc(g++)で、例外の再投入時のコアダンプ出しての終了を止めさせる方法と。

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

#include <iostream.h>

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

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

>>221
"トライ"は char const* だから、 catch( char* ) にはマッチしない。
マッチするハンドラが見つからないからabort()逝きで正しい。
キャッチしてしまうbccがクソ。

文字列リテラルは互換性のためchar*だけど？

きゃは、bccの糞さ加減が露呈（ﾌﾟｹﾞﾗ

>>222
なるほど、そういうことでしたか。
成功しました、どうもありがとうございます。

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

>>223
throwに文字列リテラルを書いた場合はその変換は起こらないことが明記されているようだ。
FDISの 15.1 -3- に記述がある。

>>186
よくわからないけど、stderrの話？

鼻毛真拳の話

鼻毛真拳の話

ところてんの話。

operation;
if (failed) {
　rollback;
}

よりも

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

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

...
の部分で失敗する要因がないなら自分で投げるのはアホだな。
あるならありかもね。

>>231
C用のフレームワークをラップするときは普通でしょ。
返り値エラーから例外への変換ね。

http://www.atmarkit.co.jp/fjava/javatips/005eclipse002.html
　＠IT > Java Solution > Java TIPS > すべての例外クラスを捕捉する
　Eclipse活用編
Eclipseですべての例外クラスを捕捉する

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

>>234
printStackTraceだけかよ。
まったく、いやな例外処理だな。
それじゃ例外おきてもログ吐くだけでそのまま処理がすすむつーの。
無い方がマシ。

IDEでTODOを自動生成したりそれを一覧表示する機能はMSの特許に抵触するな。
Eclipseからは送球に削除した方がいい。

IDEに組み込まれたTODOってDelphiの昔から存在するような気がするが

BorlandはMSとクロスライセンス契約を結んでるから無問題

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

申請前から広く使われていた周知の技術って、無効じゃないか？

そう思うならそう申請するしかない

>>239
そうです。
日本の特許庁の立場は、それは裁判所の扱う問題で、
特許庁は、初めての申請であればそれを受理する、というものです。

>>236
Eclipse3.0ではそのと挙問題を見事に解決しているぞ。
もうひとつ種類の異なるウィンドウに表示されるようになることで
解決したんだから無問題

>>235
それだったらCode Templatesを自作してしまえばいい。
コードアシスト機能でもパターンを追加すると楽だ。

それと、Jakarta Velocityも使え。

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

>>241
JavaScriptのポップアップ特許を思い出したよ。
無効になったけどなw

例外って関数外へのthrowを禁止した方が
使える気がする。

頼むからネタだといって

予言しよう！
>245は次に、例外使った処理ジャンプを「発明」する！

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

関数外へ飛び出すのを禁じた例外か・・・
ちょっと欲しい

>>248-249
ドカタ作業ばっかやってると偏るぞ……
例外もいちど復習してこいや

お前の書くコードは、エントリから終わりまで1関数なのか？
いくらドカタでも、そんなコードばっかり書いてると首になるぞ？

>>248
ムダな経験だたネ

スレタイからして糞スレかと思ったら、意外に良スレでワロタ

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

>>248>>254
まとめて逝って良し

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

>>255
裁量範囲で例外は使いません。

>>256
裁量って何か知ってるか？

>>254
> 全部例外安全にするのもコスト（コード的にも、実行時的にも）がかかりすぎるし、

同じことを、

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

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

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

まぁ趣味でやってる人は例外使わなくてもいいんじゃないの？

言葉が足りなかった。私が言いたいのは強い例外安全
(呼び出し前と例外発生後で状態の変化がない事)の事です。

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

ageてしまった。sry

>>258
まあ>>258のコードは冗長だけど
見通しは良いわな。

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

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

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

そういうときこそ

public void finc1() {
　try{

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

あとは、例外クラスを自作するとかな。
Exceptionクラスを継承してな。

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

キャッチした例外をため込みテクニックもある。

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に例外オブジェクトを蓄積してゆく。
そうすると例外情報が上書きによって隠蔽されることもなく、
欲しい例外情報を確実にはき出してくれる。

しかし例外というのも考えると難しいよ。
例えばゼロ除算だが、これの例外処理って必要だろうか？
例外として起こりうる可能性がある以上設けるべきだろうか、
しかし、そもそもまともなコードを書いていればゼロ除算など
ありえない訳で。
ありえないならそもそも例外なんて考えなくていいんじゃないか
みたいな。

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

>>266
ゼロ除算はJavaなら無問題だが。
では新たにそういうものを実装するにはどうすればいいか？
RuntimeExceptionクラスを継承するが
それをなにかしらクラスに組み込まないといけない。

データのvalidationをする部分と
データの実処理をする部分を
分けて作ればいいじゃん。

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

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

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

おまいら、例外投げまくるライブラリは作るの楽ですよ。（たぶん）

>>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に格納しなくても連鎖的に保持できるよ。

>241
亀レスだが嘘書くな。特許の三つの条件言ってみろよ

>>271
func1がexeption1「しか」throwしないなら、ね。
func1〜4それぞれがexeption1〜4の全てをthrowし得るならどうする？

>>266
Connection refused

>>271
C#ではJavaにあるthrows宣言が存在しない対策をどうとっているのか是非とも教えて遅れ。

>>275
throwsに対応する機能はないよ。ノーガード。
throwsネタは21世紀における新宗教論争だからここでは意見してあげないｗ

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

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

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

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

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

>>277
>ただ、例外を処理するのはいいが、ログに出力しただけで、
>例外が発生してない場合と同じ処理を続行するなんてコードを書かないこと。
理由を聞きたい

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

例外派は、除算する前にゼロチェックしないの？

０割するような入力してきたやつに対して、
関数側はどう返事したらいいんだ？
例外か返り値で返すしかないだろ。

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

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

除算する前にゼロチェックって…

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

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

>>276
C#はバグを減らすことよりも利便性を重視したからthrowsをはずしたんだと思っている。

>>283
リンク先読んだか？そんなこと言ってないよ。

彼が本当のことを言うと思うかい。
彼が本当のことを言わないのはほとんどが
お金のためなんだよ

（ ．３．）　ボボボーボ・ボクは例外処理が嫌いなんだなNA

（ ．３．）　ボボボーボ・ボクは例外処理が嫌いなんだなNaN

（ ．３．）　ボボボーボ・ボクは2ちゃんねるの人気者だYO
　　　　　　 ぽろじょあ#ぽろっぽ

ほら、>>282 が空気読まないで書くから、変なのが来ちゃったじゃないか。

別のスレに居るのを真似して>>286書いたけど、
>>287と>>288は俺じゃないよ

すまんな。

　　　　　もそもそ
　　　　　　　 ,､ｯ.ｨ,　　
　　　　　　,:'ﾞ　　　 ';　
　　　　((　ﾐ,;:. 　　,ｯ　)))
　　　　　　　ﾞ"'''''"ﾞ
　　　もふっ
　　　　　　　ﾊ,_,ﾊ
　　　　　　,:' ´∀｀ ';
　　　　　　ﾐ,;:. 　　,ｯ　　ﾉﾉ
　　　　　　　ﾞ"'''''"ﾞ
　　　ﾎﾟｨﾝ　
　　　　　　　ﾊ,_,ﾊ　　ﾎﾟｨﾝ
　　　　　　,: ´∀｀ ';
　　　　　　ﾐ,;:. 　　,ｯ
　　　　　　　ﾞ"'''''"ﾞ　
　　　　　 ヽ 　ｉｌｉ　/　
　　　　　-　　　　　 -

　　　　　　　　　　　ｽﾀｯ
　　　　　　　ﾊ,_,ﾊ,
　　　　　　n' ´∀｀,n,
　　　　　　ﾐ,;:.　　 ,ｯ
　　　　　　 ｀'u゛-u'

　　　　　　　　　　　　ｽﾞﾋﾞｼｯ
　　　　　　　ﾊ,_,ﾊ
　　　　　　,:' ´∀｀';9m　＜age！
　　　　　　ﾐ,;.っ　,,ｯ
　　　　　　ι''"ﾞ''u

（ ．３．）　ボボボーボ・ボクは例外処理が嫌いなんだなNaN

（ ．３．）　ボボボボーボ・ボクは例外処理が嫌いなんだなNaN

いやつまんねぇから

こいつを使えば例外処理もかなり楽になるでえ。
いちいち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

例外処理が嫌いな皆さんへ。

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

>>297
期待通りの動きだ。

（ ．３．）　ボボボーボ・ボクは例外処理が嫌いなんだなNaN

C++では例外処理なんて不要。男は黙って戻り値確認

C++では戻り値確認なんて不要。男は黙って例外処理。

C++なんて不要。男は黙ってろ

>>297
>>563と>>536とを間違えているだろ？
間違いを見つけるのに苦労したぞ。
まったく、最近こうﾚｽ番号を間違える奴が多すぎてウザイ

亀レスしときながら最近とか言うな

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

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

それは例外には責任無いだろｗ

>>307
俺が言いたいのは
例外とスレッドは相性悪いってことだよ。
C++は言語仕様で保障されてないからそれ以後怖くてな、
ミドルウェアの解析までやらされたんだぜ？
例外の仕様がこんなんじゃやってられねーよ。
クソコード書いたミドルウェアのアホ（逃げた）が一番悪いんだが、
不慣れで例外使われるより値返された方がマシだろ。

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

例外を処理できる位置で捕らえないで、文句言ってるってことですか？
返された値をチェックしないでスレッドまたぐのとどう違うんですか？

↑おまえ、ミドルウェアのアホ並の思考回路だな。

例外に責任無いじゃん。

無いよね？

例外処理大好きな俺は orz

俺なんか一日に3回は例外投げてるけどね。

>>309
あのライブラリね。
俺もはまったことあるよ。
try・・・catchって書けば普通に動くようになるよ。

ここのが相応しくないか？

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

例外はちゃんとキャッチしろよ

↓例外

│　　　 _、 _
│　 ヽ（ д` ; ）ノ
│　へﾉ　　 /
└→　ω ノ
　　　　 　 >

｜　　 ∧＿∧
｜　　（ *´Д｀）
｜　　人　ヽﾉ､
└―（　 ヽ_つ,,,つ
ﾌﾟｽｯ　）　 ））
　　　（＿_））

>>308>>309
例外だからこそ、すぐに問題が発見されたのであって、
エラー原因を返り値で渡し損なっている、
って問題ならもっと発見しにくかったはず。

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

ただのよくあるタイプのバグの一つだろ

>>305
ちゃんとロギングしろよ。
今ならアスペクト指向プログラミングによって
さらにロギングが楽になったぞ。

>>324
得体の知れない処理系なんか仕事で使えるかっての

>>325
処理系というほどのものじゃないだろ。
JBoss
Spring
Seasar
など、盛りだくさん。
勝手に選べ。
いまならDIというオマケつき。

>>326
世の中には「自社開発でない＝得体の知れない、使えない」っつー思考する所がゴマンとあるのさ･･･

きっと規模が大きいだろうに、AOPの実装もできないのか？

ほほほほほほほほほほ保守

「ボボ」は一部の地域では放送禁止。

>>330
どこ?

>>331
気になるんなら、検索するか
日本全国の女性と付き合って「ボボ！」って
叫んでみて、ひっぱたかれたらそこだッ！

>>96
newの再配置構文を知らないみたいね。realloc的なものが
ないわけないでしょ。

一年前のレスに向かって語りかける気分はどうだい？

placement newはreallocとはぜんぜん違う気が

>>324
アスペクト嗜好の資料を読んで
ログに使えると思った奴は素人

}catch(...){

これでcatch all

}
catch(Throwable e){
//>>1-337

}

頼むからさぁ、Effective JavaやMore Effective C++の例外処理の項とか
Exceptional C++とかぐらい読んでくれないかなあ。

強制させるならその本買ってきてよ

Effective VB.NETがでたら読みます

批判するならするだけの前提知識を持ってからにしろよと言ってるんだ。

むしろこれらはC++やJava使うなら最低限の必読書だと思うが

.NETの例外関係の設計はどうなの?

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

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

↓待ってましたとばかりにthrows厨登場

↑おい、出鼻くじくなよ(w

>>344
例外キャッチしなくてもコンパイルとおるんじゃないか？
あんまいい作りとは思えんが

そりゃ言語の仕様でしょ。
APIの設計はどうなんだろうねえ。
MSDNをちらっと見てみたけど、概説はまだないね。

>>347
ttp://msdn.microsoft.com/vcsharp/team/language/ask/exceptionspecs/default.aspx

VB6で、例外が起きた場所をキャッチして
画面ポップアップMSGにだすことは可能ですか

assertと例外の使い分けってどうしてる？

ライブラリの仕様としてのチェック（引数の正当性やメソッドがコール可能かどうかなど）は例外
デバッグ中のチェックコードはassert

例外の使い方わからない(´Д｀)


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

　　return true;
}

これじゃだめ？(´Д｀)

>>353
↓こっちのが幸せな気がしないかい？

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

つーかよ、353は例外出た場合、
bool で true false 以外に unknown として例外を返す必要があるとは思わないのか？

OresamaFuncは正常に処理できた実行結果としてtrue falseを返す訳だから
そもそも処理自体が行えなかった場合にはunknown(処理できなかったよ)として
どういう理由で処理できなかったかの例外を関数の呼び出し元に飛ばすべきだろ。

例外発生時に「あぁ、このエラーは漏れの処理ではありうる事なんだYo」と、
呼び出し元が考えるか、「何じゃこりゃ？」と考えるかは
OresamaFancが判断すべき状況じゃないからとりあえず上に例外を投げるんだ。

そしたら、OresamaFancを呼び出した奴が例外を受け取ったときに
適切に判断してくれる(はず)ってのが例外のそもそもの考え方じゃねぇのか？

まぁ、354が考えたように
処理が行えたらtrue で行えなかったら false っていうレベルの関数なら
無理に例外投げないで353の実装でもいいと思うけどな。
呼び出し元で

if (OresamaFunc()){
OredayoOre();
}else{
Shoboon();
}

っていう書き方できるし、そっちのほうが漏れ的には好みかな。
例外機構を使うと

try{
OresamaFunc();
OredayoOre();
}catch(OresamaError e){
Shoboonn();
}

見たいな感じで、if文を目の敵にしたのはいいが、
本質的に何も変わらないコードっつーのもなんだかなぁ。

A「例外は工数短縮に有効だよなあ」
B「ミスも少ないですよね」
C「例外はタイピング早いですよね」
A「例外はタイピングしないよ。なあ？」
B「しませんよ、例外は」

>>355
話になんねぇよ。Unknownって何だよ。意味わかんねぇ。
SQLやりすぎて頭おかしくなった糞コボラ？
BOOLは2値を返す。それが全て。

>>358
失敗も含めると、結果が２値に収まらないのが問題なんだよ。

>>1..359

C言語なみのバカだなｗ

なぁなぁ、>>357の言ってる意味がさっぱりわからないんだけどどういうこと？

明日10時に起きてサンデープロジェクト見ればわかる

try
{
Mekuso();
Mimikuso();
Hanakuso();
}
catch
{
Apoon();
}

例外好きくない！でも、他のPGが書いたコードが例外をthrowしたり、する可能性がある場合は
try..catchしとかないとなぁ
でもやっぱ自分はthrowはしないでつねー

こんなプログラムでよければ例外って便利な気がする。

try{
処理1();
処理2();
処理3();
処理4();
処理5();
}catch(Exception e){
MessageBox("エラーが発生しました。ゴメンナサイ。理由は " + e);
}

基本処理と例外処理が分離されててみやすいし、例外を見落とすこともない。

でももっと厳密な例外処理が必要になると基本処理と例外処理が入り交じって逆にわかりづらくなるのかな。
経験ないからわからないんだけど。

つかぬ事を聞くけどボーボボのアニメってどうなったの？

そもそも例外なんてシステム無くても困らないだろ。

最初から必要の無いシステムを後からつけたんじゃないの？

例外を含んだコードなんてものは、
例えば、参照をコードの方でｎｕｌｌかどうかﾁｪｯｸして、
ｎｕｌｌだったら例外を返すのではなく、引数を返して、
受け取った方で、上手く行かなかった場合のコードを書くようにしたらそれで良いんだろ。

それとも、例外処理でなければ上手く処理しきれない場合ってあるのか？
知ってる人居たら教えてくれ。

(ﾟдﾟ)ﾎﾟｶｰﾝ

おれは関数呼び出しがいらないと思う
関数という単位で無理やり括るからプログラムが歪になるんだと思う
例外処理も変な制御になる

関数や分岐のネストじゃなくて
フリースタイルに地図のように表現すれば自然に記述できるんじゃないだろうか
おまえらがフローを紙に書くように、だ

まずはメール欄にsageと入れてみよう

>>367
A から B を、B から C を呼び出しているとすると
　　B で C の戻り値をチェックし、A は B の戻り値をチェックする。
　　エラーの詳細内容 (メッセージ等) はまた別の手段で得る。
というのと
　　A で例外をキャッチしたら詳細内容も含めて入っている。
というのとでは、どっちが楽だと思う？

>>369
と思う人は、そうやって大盛りスパゲティ作ってればいいと思う。
>おまえらがフローを紙に書くように、だ
フローとてブレークダウンはしている。尤も、今時そんなもん書かないが。

ExecutableUMLはどうなったのかなぁ・・・

俺は.NETで例外はThrowせず、イベントで通知するように設計することがあるなあ。
例外の内容は例外オブジェクトをメンバにもつEventArgで通知。

これってやっぱり異端かなあ。
でも楽でいいんだよねえ。VB.NETだと特にイベント扱うの楽だから。

>>369の皮肉にﾏｼﾞﾚｽする>>371に萌え

>>369
言いたいことはわかる。

グラフ構造で表現できればすっきりするだろうね。

>例外処理でなければ上手く処理しきれない場合ってあるのか？

無いな。

ボボボボボボボボ
って方言でなんかエロい言葉なの？

なんかのマンガのキャラらしい。
単に>1が消防なだけ。

例外を、単なる別のエラー処理技法のように扱ってはいけません。
エラー コードを返したり、グローバル変数の設定したりすることと
同レベルだと思ってはいけません。例外は、それを取り巻くコードの
構造と意味を、根底から覆します。例外は、プログラムの実行時
セマンティックを一時的に繋ぎ変え、通常実行しているコードを迂回し、
こういう状況でなければ決して実行されないコードを動作させます。
例外は、エラー状態を認知させ、プログラムの死という罰則を用いて
その状態を改めようとします。

このように、例外には単純なエラー処理を超えた特性があります。
これらの特性を必要としない、理解しない、あるいは文書化したく
ないなら、例外をスローしてはいけません。
例外以外のエラー処理技法を探してください。

>>378
山下清画伯だとおもうが

>>377
福岡とか熊本あたりかな。
メメジョってのは鹿児島だっけ？

>>377
↓のスレを読めばどんなに偉大な言葉か理解出来るかも。

http://comic6.2ch.net/test/read.cgi/csaloon/1122393817/l50

結論。
例外は、無くても良いものを後から無駄につけただけ。

ドキュメント書く習慣無い奴はC++の例外使うなってことかな。
特にC++の例外機構は欠陥だらけなので。
他の言語だったら大丈夫なケースはあるかと。

>>383
だから例外をよく理解できない自分は悪くない、ということにしたいのですね。

>特にC++の例外機構は欠陥だらけなので。

初耳です;)

Deep C++ 例外処理では欠陥だらけと言ってるけど

>筆者は EH の基本的デザインは非常にしっかりしていると信じていますが、
>その一方で EH でいくつかの意図的でない深刻な結果が生じるということも
>疑いません。しかし、筆者は C++ 規格の作成者らに先見の明がないと言っ
>て責めるのではなく、効果的な例外処理を設計して実装することがどれだけ
>難しいかということを心に留めています。

遠まわしに欠陥だらけと言ってる。

具体的に挙げてみますか?

・型が弱い。関数プロトタイプに許容する例外クラス木を列挙指定できない。

>>388
C++にも欠陥はあるが、例外処理そのものが難しいことも忘れてはいけない。
と言っているように読める。

>>389
> ・型が弱い。関数プロトタイプに許容する例外クラス木を列挙指定できない。

これは関数の例外仕様のこと？ int f() throw exception; // ←コレ？
例外仕様が無いことは欠陥とは言い切れないよ。

Javaのthrowsは欠陥仕様。
後発のC#では削除されている。

>>391
どのあたりが欠陥なのか簡単に説明してくれるかな？

>>369
そこでContinuation渡しですよ。

>>393
実現イメージは出ないけど、continuationみたいなのは結構いいかもしんない
Javaのexceptionより、system call　の返り値のerrnoを見るほうが好きな俺は
比較的賛成だ
うまく例外処理コードを通常処理コードと分離（隠蔽）出来るといいんだがなあ・・

>>391
C#のthrows削除は欠陥仕様。
先発のJavaの利点を殺している。

Java でも、RuntimeExceptionを継承して例外クラスを定義するようにして、
throwsを書かないようにするのが、今の流れだと思っていたが。

というか、そういう記述もできるという事でしょ?
細かくチェックさせることもできる。

>>396
意味ねーじゃんｗ
ちゃんと例外設計しろよｗ

Hibernate 2.x のスローする例外はchecked例外だったけど、
Hibernate 3.x からは unchecked例外になった。
Springの例外も、すべて RuntimeException を継承している。

詳しくは Expert One-On-One J2EE Design and Development を参照してくれ。

E・∇・ﾖﾉｼ　＜400ｹﾞｯﾄ♫

RuntimeExceptionと「通常」のException
の違いが解っていない人多いよね
C++もこの違いを意識して書けば、これほど便利なものは無いのに
先ずはExceptionの設計をしないで使ってる事が問題

どっちも一緒だ。例外は例外。両方とも平等に扱うべき。

全部平等にException catch かよｗｗ

両方一緒（ごちゃ混ぜ）にして、try〜catchのコードの山と
格闘してる開発部隊がいたの思い出した
テストとか見ていて、ちょっと気の毒だった

例外的な事が起きても継続を続行しなくてはいけないアプリにとっては
無責任な例外送出は迷惑極まりない。>>379でほとんど言われてしまったけど。