ボボボーボ・ボクは例外処理が嫌いなんだな
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
NGNG何の例外が飛んでくるかわからないクラスなんて怖くて使えない
そもそも例外処理って大域ジャンプだろ、
そんなもの怖くて使えねーよ
0002デフォルトの名無しさん
NGNG0003デフォルトの名無しさん
NGNG0004デフォルトの名無しさん
NGNG取りあえずJavaとC++では対策が既に成されてる。
0005デフォルトの名無しさん
NGNG0006デフォルトの名無しさん
NGNG0007デフォルトの名無しさん
NGNGRubyつかってるからわからないけど、なにかあるなら教えて。
0008デフォルトの名無しさん
NGNGメソッドに何が飛んでくる可能性があるか書いてあるだろが。
0009デフォルトの名無しさん
NGNG次スレです。
http://pc2.2ch.net/test/read.cgi/tech/1065535118/
0010デフォルトの名無しさん
NGNG0011デフォルトの名無しさん
NGNG頻繁に呼ぶもんじゃないし、いいんじゃないの。
0012デフォルトの名無しさん
NGNG例外とはめったに起こらないから例外なんだから遅くてもいいだろ
0013デフォルトの名無しさん
NGNG言語自体にも対策方法があるの？
0014デフォルトの名無しさん
NGNG本来は例外として分類されるべき処理はいくらでもありそうだが
0015デフォルトの名無しさん
NGNGそんなに速度が要求されるのに例外にされるべき処理って何?
0016デフォルトの名無しさん
NGNG0017デフォルトの名無しさん
NGNG0018デフォルトの名無しさん
NGNG0019デフォルトの名無しさん
NGNGgoto先にまずまとめたりしない？
0020デフォルトの名無しさん
NGNGVBっていうと敬遠されるかもしれんけど（ｗ
0021デフォルトの名無しさん
NGNG自然と正常系以外は全て例外扱いになるが。
00221
NGNG今仕事で修正しているプログラムはただでさえぐちゃぐちゃなのに
例外処理使われていて目も当てられない
その上、キャッチのし忘れも多過ぎ
百戦錬磨の俺でさえ逃げ出したくなる。もう例外キライ
本来、エラー処理の抜けをなくしたりシンプルに扱うための例外処理だった
はずなのに、実際は抜けは多くなるし流れも見えづらい
俺にはＧＯＴＯ文より極悪に見えて仕方がない
0023デフォルトの名無しさん
NGNG途中スコープの外れるインスタンスのデストラクタを読んでくれたりかなり高機能ですけどね。
0024デフォルトの名無しさん
NGNGVBのそれにはまねできないわけだ。
0025デフォルトの名無しさん
NGNG一応、メンバ関数の宣言の後ろにthrowをつけれるけど、
あってもなくてもコンパイルできちゃうわけで。
0026デフォルトの名無しさん
NGNG付けてもVCはthrow() (例外を投げない宣言)以外は未実装警告だして
使えないしね・・。VC7.1のISO仕様残り2%のひとつだ。
0027デフォルトの名無しさん
NGNGオブジェクトの終了を通知するための手段として
例外を使ってるんだわさ。
で、例外を受け取った外側の処理でそのオブジェクトへの
参照を外すようにしてる。
こういう使い方ってしないほうがいいのかな・・・？
0028デフォルトの名無しさん
NGNG＞そもそも例外処理って大域ジャンプだろ
例外処理を勘違いしてそんな書き方するやつがいるだけだ
0029デフォルトの名無しさん
NGNGへーそうなのか、C++はコンパイルとおっちゃうのか
そりゃあわけわからんプログラマが前工程やるとわけわからんくなるわな
0030デフォルトの名無しさん
NGNGそういう例外の使用法は、よく悪い例として取り上げられています
C#は詳しくないけど、デストラクタってありましたよね？
003127
NGNGデストラクタはありません。（ファイナライザはありますが…）
C#では基本的にＧＣがメモリの後処理をしてくれます。
やはり例外を通常処理として用いるのは良くないのですか？
0032デフォルトの名無しさん
NGNG0033デフォルトの名無しさん
NGNG＞やはり例外を通常処理として用いるのは良くないのですか？
これは当たり前として。
003427
NGNGわかりました。bool値を返すように変更します。
0035デフォルトの名無しさん
NGNG0036デフォルトの名無しさん
NGNG使うというやつがいて困ったことがあるなぁ
呼べば、ほとんど確実に例外を投げるという・・・ カンベンしてくれ。
0037デフォルトの名無しさん
NGNG｢ほとんど確実に例外を投げる」と言うのは、ちょっとおかしいと思うけど。
0038デフォルトの名無しさん
NGNG例外機構じゃなくて大域脱出機構にでもすればよかったんだよ。
0039デフォルトの名無しさん
NGNGこの世に使っているすべてのプログラマが統合開発環境を使っているとは限らないので
そういうものに頼る手法は却下
0040デフォルトの名無しさん
NGNGまたはそのサイトや書籍をおしえれ
0041デフォルトの名無しさん
NGNG0042デフォルトの名無しさん
NGNG例外に特化した本でなくてもいい。
なにかおすすめがいい。
鉄則本や落とし穴本でもいい
0043デフォルトの名無しさん
NGNG例外処理の手順について理解を深めろ。
0044デフォルトの名無しさん
NGNG生成して開放が必要なオブジェクトを廃棄し処理を停止させてるけどだめ？
0045デフォルトの名無しさん
NGNG0046デフォルトの名無しさん
NGNG例外とは関係ないけど，もしかしたら
"NullObject パターン" を挙げると喜ぶ？
0047デフォルトの名無しさん
NGNG投げるべき例外をしっかりとつかみちゃんと正しく例外が処理されるのか？
0048デフォルトの名無しさん
NGNGWindowsは知らんのだが、言語で処理するのは
あまり好きくなれん
0049デフォルトの名無しさん
NGNGそれは普通割り込みという
0051デフォルトの名無しさん
NGNG裸の大将じゃないの?
0052デフォルトの名無しさん
NGNG一般常識に疎いということはオタクだろ、お前。
0053デフォルトの名無しさん
NGNG0054デフォルトの名無しさん
NGNG純粋に若いだけかも。何年前だよ、裸の大将って
0055デフォルトの名無しさん
NGNG仮に例外処理以外の方法(エラーコードを戻り値で返したりグローバル変数に格納したり)
を採用したところでその環境じゃまともに機能しないだろ。
責任を例外処理に押し付けたところで何も問題は解決しない。
例外を投げるやつはドキュメントに明記しろ。
メソッドをコールする奴はドキュメントを嫁。ただそれだけ。
0056デフォルトの名無しさん
NGNG0057デフォルトの名無しさん
NGNG0059デフォルトの名無しさん
NGNG喜べるとはいえない。。もしそれが逆ならギャグいわれたってそれだけでは現実には何も進展がない。
Javaの鉄則に、「例外を隠さない」手法として
Vectorにcatchされた例外を詰め込んで最後に吐き出し表示するという技が
あった。
しかし汎用性が感じられなかったなあれは。
既存の数多くの例外クラスにそんな機能が最初から
そなわっていればあんなつかいかたも考慮したのだが・・・。
Throwableクラスのメソッドをどうにかして使えばいいのか・・？
0060デフォルトの名無しさん
NGNG0061デフォルトの名無しさん
NGNG逆にC#の例外書かなくてもコンパイル通っちゃうのは不安でいけない。
って書くとまた荒れる元になるかな。
0062デフォルトの名無しさん
NGNG0063デフォルトの名無しさん
NGNGああっ！！出ちゃう！！例外出ちゃいますぅぅぅぅぅぅ！！！！！！！
ということで
----------------------終了-----------------------
0064デフォルトの名無しさん
NGNG0065デフォルトの名無しさん
NGNGニャロメとケムンパスはいたと思ったが・・・。
0066デフォルトの名無しさん
NGNG何言ってんですか？
0067デフォルトの名無しさん
NGNGおそまつにもいるよ。ほうきをもったやつだろ
0068デフォルトの名無しさん
NGNGメンバにList<Exception>を持つExceptionサブクラス作ったら？
printStackTrace()とかオーバーライドしといて、あとListへの
Iteratorを返すメソッド追加しとけば、そこそこ便利じゃないかね。
つうか、俺がそういうの使ってる。
0069デフォルトの名無しさん
NGNGひとつ上への参照さえもてれば連鎖的に保存しておけるんだから。
つうか、MSがそういうの使ってる。
0070デフォルトの名無しさん
NGNG何が
List<Exception>
だよ。
おまえらそれで満足か？
0071デフォルトの名無しさん
NGNGええ、その後に数十回同じキャストを繰り返すよりは。
0072デフォルトの名無しさん
NGNG＞List<Exception>
充分、きれいですが。
0073デフォルトの名無しさん
NGNG0074デフォルトの名無しさん
NGNG馬鹿やろ
破綻してるだろうが。
List<List<Exception>>
これでもうだめぽ（ｹﾞﾗ
0075デフォルトの名無しさん
NGNGList<List<Exception> >
だと思われ。
0076デフォルトの名無しさん
NGNGだから>>74は破綻しているといっているのではなかろうか。
0077デフォルトの名無しさん
NGNGほっとけよ、XXXX房は。
唯一C++のtemplateに勝てる所なんだから。
そっとしておいてやっれって。
0078デフォルトの名無しさん
NGNG例外の利点でよくでるのがスタック等のオブジェクト
破棄や、コールスタックさかのぼっていけるって言うけど、
オブジェクトの破棄はされても関数呼び出しの効果が
自動的ににロールバックされるわけでもないし。
例外のせいで中途半端なところで関数呼び出しが終わってしまう
可能性を絶えず考慮してコーディングする労力のほうが便利さを
遥かに上回っているようなきがする。
例外的な状況のために全ての関数でとりあえずcatchして
ロールバック処理＆再throwを書くのもめんどう。
0079デフォルトの名無しさん
NGNG初歩で陥るとこだ罠
0080デフォルトの名無しさん
NGNGルーティングの段階でロールバック。
ロールバックの必要な処理は型やメンバでフィルタリング。
try {
....
} catch (filter &e) {
rollback();
thorw;
}
0081デフォルトの名無しさん
NGNGお前のコードの中にfinallyってあるか？
無ければ独習シリーズでも読み直して出直せ。
0082デフォルトの名無しさん
NGNGtry {
foo();
} catch(...) {
//何もなし
}
というコードばっかりだよ。
いっそのことこう書こうかなｗ
try { foo(); } catch(...){}
0083デフォルトの名無しさん
NGNG0084デフォルトの名無しさん
NGNG0085デフォルトの名無しさん
NGNG0086デフォルトの名無しさん
NGNG＞自動的ににロールバックされるわけでもないし。
されたら迷惑
0087デフォルトの名無しさん
NGNGスタックトレース位吐けやボケ。
0088デフォルトの名無しさん
NGNG禿道。例外発生したらスタックトレース。
決り文句。常にこう書くべし↓
try {
foo();
} catch (Exception e) {
e.printStackTrace();
}
例外発生時にも処理が続行されるがｷﾆｼﾅｲ
0089デフォルトの名無しさん
NGNG0090デフォルトの名無しさん
NGNGくたばれ
0091デフォルトの名無しさん
NGNGfinallyなんてねえよ。あったらコンパイルとおらんし(w
>>86
>されたら迷惑
もちろんめいわくだ。何が正しいロールバックかなんて
機械的に決定されるものでもないと思うし。例外が自動で
やってくれることはたかが知れているじゃないかって意見。
本当に末端のライブラリが投げるんならまだ良いんだけど、
アプリケーション製作者が気軽に投げるもんでも無い気が
する。
0092デフォルトの名無しさん
NGNG0093デフォルトの名無しさん
NGNGtry {
foo();
} catch (...) {
throw;
}
これで決まりではないか。
0094デフォルトの名無しさん
NGNGあれだけゴチャゴチャした言語仕様なのに、finallyが無いってのは
けっこうビックリだよな。
最近じゃVB.NETにすら付いたのに。
0095デフォルトの名無しさん
NGNGデストラクタで各オブジェクトに後始末させるからいいんじゃないの
0096デフォルトの名無しさん
NGNGCでmallocやfree呼んでるのと実質変わらないよね。
reallocが無い時点でC++はゴミ。
例外機構なんてやめてlongjmp駆使した方が速いしわかりやすい。
longjmpでデストラクタ呼ばれないのはもうね、馬鹿（略
0097デフォルトの名無しさん
NGNGだな。
出口や入り口は少なければ少ないほど理解しやすくいいと言われてるのに、
例外処理はそれに完全に逆行してる
少なくてもC++では流行る気配すらないな
0098デフォルトの名無しさん
NGNG>出口や入り口は少なければ少ないほど理解しやすくいいと言われてるのに
気のせいです。
0099デフォルトの名無しさん
NGNG途中でリターンというのは、途中で一つの出口への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も出口は一つ。
0100デフォルトの名無しさん
NGNG0101デフォルトの名無しさん
NGNG0102デフォルトの名無しさん
NGNG今度は、そんな goto だらけのプログラムは、理解しにくいと言われるだけだぞ。
0103デフォルトの名無しさん
NGNG空気読んでよく読め
0104デフォルトの名無しさん
NGNGreallocﾜﾗﾀ
>>101
あるよ。MLは例外にも例外が返る関数にも厳密な型がついているよ。
0105デフォルトの名無しさん
NGNGttp://boost.cppll.jp/HEAD/more/generic_exception_safety.html
0106デフォルトの名無しさん
NGNG理をうまく実践できない
0107デフォルトの名無しさん
NGNG{
a();
b();
c();
}
aを呼んだらcは必ず実行しなければならない。
cを実行しなかった場合の動作は未定義であるとする。
こういう場合、bで例外が投げられたらプログラムは安全に続行不可能
という意味で破綻する。クラスに置き換えても同じだ。
{
o->a();
o->b();
o->c();
}
オブジェクト指向はこの問題を解決しない。
（C++の自動デストラクタに頼るしかない。これはＯＯとは何の関係もない）
0108デフォルトの名無しさん
NGNGそうかい?
C++例外+pthread+UNIXなら相性悪いと思うけど、
例外+スレッド一般は特に問題ないだろ。Javaとかね。
非同期I/Oやスレッドプールが絡むと嫌らしいけどな。
0109デフォルトの名無しさん
NGNGばかだなぁ。
{
try{ a(); } catch(...){}
try{ b(); } catch(...){}
try{ c(); } catch(...){}
}
とすれば手続き型と全く同じですよｗ
0110デフォルトの名無しさん
NGNG0111デフォルトの名無しさん
NGNG○とすれば例外を使わない場合と全く同じですよｗ
0112デフォルトの名無しさん
NGNGtry{ ... } catch(...){}
で囲むバカはおるまい。
0113デフォルトの名無しさん
NGNGb()だけでいいだろ。真馬鹿め。
0114デフォルトの名無しさん
NGNG例外は常に例外じゃない方法よりも便利。
0115sage
NGNGそりゃ例外使っても良い作りのプログラムにしとけばいいけど
そうするための苦労に比べ実入りが少ない気がする。
しかし、C++にfinallyが無いのは悲惨だな
RAIIへの配慮が足りないぞ
>>46
NullObjectというのはイイ手だよね
>>101
MLにはある。Haskellにも導入されそう。Lisp、Schemeにはない。
ただしSchemeでは継続をつかって例外処理することができる。
0116デフォルトの名無しさん
NGNG0117デフォルトの名無しさん
NGNG> RAIIへの配慮が足りないぞ
finallyがあったら、RAIIを実践するにあたってどんな利点があるのですか？
0118デフォルトの名無しさん
NGNG> 例外って便利か？
> そりゃ例外使っても良い作りのプログラムにしとけばいいけど
> そうするための苦労に比べ実入りが少ない気がする。
言語に例外機構があることで、例外について考える圧力が生じ、
それで、例外が「大変だ」と思う人がいるんじゃないかな。
言い換えれば、今まで例外処理をいい加減にやって来たから、大変だと思うのでは。
実際、例外機構のない言語では、例外処理の選択肢が狭く、
それを逸脱しようとすると大変なことになる。
つまり、例外機構のおかげで、例外処理に幅が出たのでは?
0119デフォルトの名無しさん
NGNG僕ちゃんは何がどう大変になるんだい？
0120デフォルトの名無しさん
NGNGreallocﾜﾗﾀ
でもたしかreallocみたいなことをできるOOPLなかったっけ？
0121デフォルトの名無しさん
NGNGbだけでいいとか言い出すと、次はtryで囲む事自体忘れる奴が現れる
そうなると、従来のif文によるエラーチェックを忘れるよりタチが悪い
0122デフォルトの名無しさん
NGNG簡単なんで、例外処理、あれもこれもやりたくならないかい?
0123デフォルトの名無しさん
NGNG> しかし、C++にfinallyが無いのは悲惨だな
> RAIIへの配慮が足りないぞ
逆じゃないの？コンストラクタ・デストラクタでRAII
を簡単にサポートできるから、finally無くても
破綻しないじゃないの？
void func() {
fstream file("file.txt");
//若しくは auto_ptr<fstream> file=new fstream("file.txt");
throw Exception;
}
0124デフォルトの名無しさん
NGNGtry {
//処理
} 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);
} とすべきかで迷う
0125デフォルトの名無しさん
NGNG同じ例外投げたいんだったらこれでいいだろ。
try {
// 処理
} catch(Exception e) {
e.printStackTrace();
throw e;
}
0126デフォルトの名無しさん
NGNG0127デフォルトの名無しさん
NGNGJava?
0128デフォルトの名無しさん
NGNGどっちでも読めるんですね。一瞬まよってしまった。
0129デフォルトの名無しさん
NGNGclass foo {
private:
void a(...);
virtual void b(...);
void c(...);
public:
void bar(...);
};
void foo::bar(...){
a(...);
try {
b(...);
} catch(...){
}
c(...);
}
ってやっときゃいいだけだろ。
0130デフォルトの名無しさん
NGNGZyaaそもそもプロトタイプ宣言すんなよ。と。
0131デフォルトの名無しさん
NGNG・誤爆。
・単なる釣り。
・単なるアフォ。
どれなんだ ?
0132デフォルトの名無しさん
NGNG0133デフォルトの名無しさん
NGNG0134デフォルトの名無しさん
NGNG{
cout << "でも聞きたい" << endl;
}
0135デフォルトの名無しさん
NGNG0136デフォルトの名無しさん
NGNG0137デフォルトの名無しさん
NGNG0138デフォルトの名無しさん
NGNGお前リリース品にもprintStackTraceみたいなデバッグプリント入れてるバカだろ。
0139デフォルトの名無しさん
NGNGお前日本語読めない馬鹿だろ。
しかもageてるし。
0140デフォルトの名無しさん
NGNG0141デフォルトの名無しさん
NGNGお前日本語読めない馬鹿だろ。
>>139は「日本語読めない」から「馬鹿だ」って言ってるんだろうが。
0142デフォルトの名無しさん
NGNGん、なんだ、125って俺の書き込みじゃん。
ということはお前は124？
0143デフォルトの名無しさん
NGNG怖い。
0144デフォルトの名無しさん
NGNGtry catchを厳密に求められるJavaは面倒くさいとも思うし、
そこらへんいい加減でもプログラムが組めるのはやってわかったが、
言語が例外処理漏れを確実に防いでくれる方がトータルで低コストだ。
0145デフォルトの名無しさん
NGNGなんか同意。VBとかK&R Cとか曖昧性のある言語って高コストっす。
0146デフォルトの名無しさん
NGNGboostにもfinally相当がないの？
0147デフォルトの名無しさん
NGNGテンプレートでどうにかなる問題なんですか？
0148デフォルトの名無しさん
NGNGフレームワークとして使うならException#printStackTrace()いれとかんと。
0149デフォルトの名無しさん
NGNGcatch & throw + unwind-protect じゃだめでつか？
原始的すぎ？
0150デフォルトの名無しさん
NGNGLISPの話をしているのか？
0151デフォルトの名無しさん
NGNG気を付けていても、どこかで内部状態の矛盾とか、資源洩れを
起こしてしまう。実は、あまり起こらないエラー、まじめな
回復をやりたくないエラーは、起こったらexit()するのが
正しいんじゃないか？
こう言うと凶悪なようだけど、スクリプト言語の世界は既にそうで、
perl/python/rubyのような汎用スクリプト言語は、「書きやすさ」
の相当部分を、「まじめなエラー処理をやらなくていい」ことで
得ている。まじめなエラー処理をやり始めたら、はっきり言って
(C++はともかく)Javaに比べて全然書きやすくない。
信頼性という面でも、まれなエラーが起こったとき、テストが不十分
であるゆえに挙動を予測できないプログラムより、直ちに異常終了
するプログラムの方が、予測可能性が高くて信頼できる。
0152149
NGNG0153デフォルトの名無しさん
NGNG0154デフォルトの名無しさん
NGNG・・・以上ロートルアボートコア吐き厨の寝言でした。
0155デフォルトの名無しさん
NGNGvoid f(shared_ptr<int>, int);
int g();
void bad()
{
f(shared_ptr<int>(new int(2)), g());
}
これがメモリリークになるというのを見たとき、意識が飛びそうになったよ。
ここまで気づくか？普通。
「俺はこんなミスしない」という自信のある人がいたら、
是非その根拠を教えて欲しいもんだ。
0156貧乏紙
NGNGあの有名な「Internal Server Error」のこと？
すばらいじゃんあれさ。
0157デフォルトの名無しさん
NGNG複雑に考えすぎなんじゃないの。だって、想定する値じゃないときとかに、一行raiseって書いて、あと捕捉すればいいだけだぞ。
デバックが楽になるから、結果として早く書ける
Ruby使ってるけど、CGI書くのにも、便利。
0158デフォルトの名無しさん
NGNG業務では使いたくないな。レビューとか検証とかしんどそう
0159デフォルトの名無しさん
NGNG0160デフォルトの名無しさん
NGNG>すばらいじゃんあれさ。
>すばらいじゃんあれさ。
人類に分かる言葉で書いてくれ。
0161デフォルトの名無しさん
NGNG誰に言ってんだよ。
0162デフォルトの名無しさん
NGNG>>153
あの有名な「Internal Server Error」のこと？
すばらいじゃんあれさ。
0163デフォルトの名無しさん
NGNGいや彼の仲間は、意外にたくさんいるぞ。
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=
もしかしたら、俺たちが異端児なのかもしれない。
0164デフォルトの名無しさん
NGNG入力ミスから発生した言い回しのひとつ。「すばらしい」の最上級。
0165デフォルトの名無しさん
NGNGすばらい
すばらいい
すばらいし
すばらいしい
0166デフォルトの名無しさん
NGNG0167デフォルトの名無しさん
NGNG0168デフォルトの名無しさん
NGNG0169デフォルトの名無しさん
NGNG「今日はバグがすぱーすぱーでした」 とか言われて意味わかるか？
オレにはわからんが、後輩にはわかるらしい。女の脳みそは理解できん。
0170デフォルトの名無しさん
NGNG0171デフォルトの名無しさん
NGNGそりゃなにか違うような。
名前違わなかったか？
そういうことはTomcatやApacheなどサーバ側の設定の
問題だろ。
0172デフォルトの名無しさん
NGNG>「今日はバグがすぱーすぱーでした」 とか言われて意味わかるか？
>オレにはわからんが、後輩にはわかるらしい。女の脳みそは理解できん。
それは結構最近のパラダイムだから、お前がまだ知らないのは許してやる。
しかし、新しい言葉を聴いたらすぐに自分で調べる癖をつけないと、
いつまでたっても恥をかき続けるぞ。
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
0173デフォルトの名無しさん
NGNG0174デフォルトの名無しさん
NGNGvoid main(void){Main();}
0175デフォルトの名無しさん
NGNGそんな言葉を知らないことを恥だと考えることの方が恥ずかしいんだけど。
0176デフォルトの名無しさん
NGNG何がしたいのか知らんがこれで十分だろ
main(){main();}
0177デフォルトの名無しさん
NGNGmain() のリンケージは、実装依存である。
main() のアドレスを使うことはできず、main() を inline や static と宣言してもならない。
■これは、プログラムとその環境の間のインターフェースの実装者に完全な裁量権を保証するためである。
■ゆえに、main() を関数として実装しないような実装を想像することさえできるであろう。
そんな実装が実在するかどうかは知らんけどね。
0178デフォルトの名無しさん
NGNG0179デフォルトの名無しさん
NGNG0180デフォルトの名無しさん
NGNG懐かしいな
0181デフォルトの名無しさん
NGNG0182デフォルトの名無しさん
NGNG死んだ。
0183デフォルトの名無しさん
NGNGthrow(10);
}catch(int i){
throw(10);
}
0184デフォルトの名無しさん
NGNG対処しないヘタレ。アサートダイアログより親切か？程度の
Windowプログラマの戯言ですた。やってることはデバッグの
延長線上でしかなかったりする。
ＯＳとかサーバとかなら何とかせにゃならんかもって気がするが。
0185デフォルトの名無しさん
NGNG0186デフォルトの名無しさん
NGNGそれをいうなら
エラー出力をリダイレクトできないMS-DOSひいては95系列の
Windowsの設計ミス。
Javaはエラー出力をファイル等にリダイレクトする必要性から
しかたなくそういう仕様になった。（Windows版だけだったかもしれん）
0187デフォルトの名無しさん
NGNG0188デフォルトの名無しさん
NGNGWindowsのせいでJavaはかような糞言語になったという主張だね？
0189デフォルトの名無しさん
NGNG0190デフォルトの名無しさん
NGNG0191デフォルトの名無しさん
NGNG必ず警告なりエラーなり出すようにすれば？
コンパイラがさ。
0192デフォルトの名無しさん
NGNG0193デフォルトの名無しさん
NGNG0194デフォルトの名無しさん
NGNG0195デフォルトの名無しさん
NGNG0196デフォルトの名無しさん
NGNG0197デフォルトの名無しさん
NGNG実際、何を勘違いしているのか、例外を正常な動作の分岐用フラグのつもりで
使うというやつがいて困ったことがあるなぁ
「例外」とかかっこつけてオブラートに包んだ表現しないで
素直に「エラー」と呼ぶようにすれば多少意識が変わるのではないかと思う。
DOSのBATだとERRORLEVELで分岐するのが通常だがな。
0198デフォルトの名無しさん
NGNG事前に決めておくのが辛くなってくると思うんだが、
その辺の対策は無し？
0199デフォルトの名無しさん
NGNG0200デフォルトの名無しさん
NGNG0202デフォルトの名無しさん
NGNGpublic class HogeException<T> extends Exception {}
があったときに
try {
} catch (HogeException<Foo> e) {
}
とかできないって話だろ？
0203デフォルトの名無しさん
NGNG0204デフォルトの名無しさん
NGNGそれをやるなら、独自のExceptionを作れと。
JavaのGenericsはコンパイル時型チェックの仕組みだしな。
0205デフォルトの名無しさん
NGNG使えない奴はあんたみたいに大抵例外放置してるよ。
RuntimeExceptionは完全無視、
後は大体catch( Exception e ) {}で放置。
エラー起きて発生箇所特定するのにハァハァ必死な顔してるよ。
0206デフォルトの名無しさん
NGNGCLUはend of fileを例外で処理する仕様のライブラリでした。
End of listはどうだったかなあ?
0207デフォルトの名無しさん
NGNG0208デフォルトの名無しさん
NGNGスレタイは、ボーボボの部分が入れ替わってると思うが。
0209デフォルトの名無しさん
NGNG正直、意味が分からん。
0210デフォルトの名無しさん
NGNGそのくらいぐぐれよ(￣ー￣)
ttp://www.tv-asahi.co.jp/bo-bobo/
0211デフォルトの名無しさん
NGNG正直、意味が分からん。
0212デフォルトの名無しさん
NGNG0213デフォルトの名無しさん
NGNG0214デフォルトの名無しさん
NGNG意味のわからなさだけがウリのマンガだからな。
0215デフォルトの名無しさん
NGNGなのにC++の場合は、コンパイラの例外処理に対する仕様が統一されてないのはなんともな。
bccでは可能なthrowの再投入がgccでは出来なかったり、
例外呼び出したことが原因で止まったりとか頭痛い。
0216デフォルトの名無しさん
NGNGお前がコンパイラとデバッガの使い方を知らないだけ。
0217デフォルトの名無しさん
NGNGそれを言われると辛いな。
んで、調べたんだけど分からないんですが、
gcc(g++)で、例外の再投入時のコアダンプ出しての終了を止めさせる方法と。
VC付属のコンパイラで、関数の例外指定可能にする方法教えてください。
後者の方は調べた先では無理みたいな英文が載ってたんですが、
隠しオプションか何かあるんですか？
0218217
NGNGじゃなくて、関数の例外型指定でした。
0219あいタン ◆3QC.t4i5w6
NGNG( ノ￣∇￣)ノ みんなーーーーーーー、あいでーーす!!(￣ー￣)ニヤリッ
またーーーーり
0220デフォルトの名無しさん
NGNG> gcc(g++)で、例外の再投入時のコアダンプ出しての終了を止めさせる方法と。
例外を再投入してコアダンプ出して終了するソースをみせてくれませんか？
0221デフォルトの名無しさん
NGNGmain( )
{
try
{
try
{
throw "トライ";
}
catch ( ... )
{
cout << "全ての例外を捕まえた" << endl;
throw;
}
}
catch ( char *s )
{
cout << "メッセージ: " << s << endl;
}
}
これなんですけど、bcc32では問題ないんですが、
g++だと再投入時に停止するんですよね。
0222デフォルトの名無しさん
NGNG"トライ"は char const* だから、 catch( char* ) にはマッチしない。
マッチするハンドラが見つからないからabort()逝きで正しい。
キャッチしてしまうbccがクソ。
0223デフォルトの名無しさん
NGNG0224デフォルトの名無しさん
NGNG0225デフォルトの名無しさん
NGNGなるほど、そういうことでしたか。
成功しました、どうもありがとうございます。
しかし、これbcc厳しいですね。
const char *もchar *両方マッチングしてしまうんですね。
0226デフォルトの名無しさん
NGNGthrowに文字列リテラルを書いた場合はその変換は起こらないことが明記されているようだ。
FDISの 15.1 -3- に記述がある。
0227デフォルトの名無しさん
NGNGよくわからないけど、stderrの話？
0228デフォルトの名無しさん
NGNG0229デフォルトの名無しさん
NGNG0230デフォルトの名無しさん
NGNG0231デフォルトの名無しさん
NGNGif (failed) {
rollback;
}
よりも
operation
if (failed) {
throw;
}
....
catch() {
rollback;
}
の方がどう考えても見苦しいんですが、
フレームワークの方で例外を投げてくれない場合も自分で例外投げるのって普通なんですか？
0232デフォルトの名無しさん
NGNGの部分で失敗する要因がないなら自分で投げるのはアホだな。
あるならありかもね。
0233デフォルトの名無しさん
NGNGC用のフレームワークをラップするときは普通でしょ。
返り値エラーから例外への変換ね。
0234デフォルトの名無しさん
NGNG＠IT > Java Solution > Java TIPS > すべての例外クラスを捕捉する
Eclipse活用編
Eclipseですべての例外クラスを捕捉する
こういう機能があると例外を積極的に試用することも惜しまなくなる。
0235デフォルトの名無しさん
NGNGprintStackTraceだけかよ。
まったく、いやな例外処理だな。
それじゃ例外おきてもログ吐くだけでそのまま処理がすすむつーの。
無い方がマシ。
0236デフォルトの名無しさん
NGNGEclipseからは送球に削除した方がいい。
0237デフォルトの名無しさん
NGNG0238デフォルトの名無しさん
NGNGhttp://japan.cnet.com/news/ent/story/0,2000047623,20069128,00.htm
0239デフォルトの名無しさん
NGNG0240デフォルトの名無しさん
NGNG0241デフォルトの名無しさん
NGNGそうです。
日本の特許庁の立場は、それは裁判所の扱う問題で、
特許庁は、初めての申請であればそれを受理する、というものです。
0242デフォルトの名無しさん
NGNGEclipse3.0ではそのと挙問題を見事に解決しているぞ。
もうひとつ種類の異なるウィンドウに表示されるようになることで
解決したんだから無問題
0243デフォルトの名無しさん
NGNGそれだったらCode Templatesを自作してしまえばいい。
コードアシスト機能でもパターンを追加すると楽だ。
それと、Jakarta Velocityも使え。
EclipseのVelicity UIプラグイン、 Simteecプラグインを使うと楽だ。
0244デフォルトの名無しさん
NGNGJavaScriptのポップアップ特許を思い出したよ。
無効になったけどなw
0245デフォルトの名無しさん
NGNG使える気がする。
0246デフォルトの名無しさん
NGNG0247デフォルトの名無しさん
NGNG>245は次に、例外使った処理ジャンプを「発明」する！
0248デフォルトの名無しさん
NGNGそこが源流となる例外を放つケースは無いと断言出来る。
例外は全てその下のレイヤー(APIとか標準ライブラリ)から飛んでくる。
そして、それらの例外は復旧不能なものが殆どで、例外が起きた時点でアボーンが常。
だったら、自分の書くコードでは関数外例外は禁止した方が
書くコード量が減って見やすくなっていいんじゃないかにゃ〜ん
0249デフォルトの名無しさん
NGNGちょっと欲しい
0250デフォルトの名無しさん
NGNGドカタ作業ばっかやってると偏るぞ……
例外もいちど復習してこいや
0251デフォルトの名無しさん
NGNGいくらドカタでも、そんなコードばっかり書いてると首になるぞ？
0252デフォルトの名無しさん
NGNGムダな経験だたネ
0253デフォルトの名無しさん
NGNG0254デフォルトの名無しさん
NGNG同意
アプリケーションレベルのオブジェクト間通信って関数呼び出しだけに
マッピングするとは限らんので、エラー通知の汎用的な解として
例外はいまいちしっくりこない。
全部例外安全にするのもコスト（コード的にも、実行時的にも）がかかりすぎるし、
そうでない場合は、関数呼び出し順序等に強い依存関係が生まれそうでこわい。
0255デフォルトの名無しさん
NGNGまとめて逝って良し
プログラマの裁量範囲でうまく使え
0256デフォルトの名無しさん
NGNG裁量範囲で例外は使いません。
0257デフォルトの名無しさん
NGNG裁量って何か知ってるか？
0258デフォルトの名無しさん
NGNG> 全部例外安全にするのもコスト（コード的にも、実行時的にも）がかかりすぎるし、
同じことを、
result1 = func1(arg11, ...);
if (result == -1) {
// ああした
}
result2 = func2(arg21, ...);
if (result2 == -1) {
// こうした
}
でやるより簡単だから、例外が最近の言語にはあるんだが。
callerで処理すれば済めば簡単なんだが、
callerのcallerのcallerで処理しないと行けない場合大変だ。
実際qmailのコードをみるとほとんどがエラー処理だ。
機能をprocessに分割しているserverでもまじめに書くとああなる。
0259デフォルトの名無しさん
NGNG0260デフォルトの名無しさん
NGNG(呼び出し前と例外発生後で状態の変化がない事)の事です。
>>258
func1の実装とそれを呼び出している実装の関係が汎用ライブラリのコードと
アプリケーションコードの関係だってんなら同意するけど。
コンテキストを多く持つAppレベルのオブジェクトの場合、強い例外安全を
各メソッドで実現するコストが高すぎるってのが、私の感覚。
勿論、全メソッドで強い例外安全を確保して再利用性を高めうようって発想も
わかるけど、そもそも、Appレベルのコードって再利用する事自体少ないし。
ライブラリってんなら話は別だけど。
0261254=260
NGNG0262デフォルトの名無しさん
NGNGまあ>>258のコードは冗長だけど
見通しは良いわな。
try{
func1(...);
func2(...);
func3(...);
func4(...);}
catch( exception1 e){ ...}
catch( exception2 e){ ...}
catch( exception3 e){ ...}
catch( exception4 e){ ...}
これでは、すっきりしているが相関がわからない。
そこいら辺の情報がスッポリ抜け落ちているからな。
また、どの関数がどの例外を投げる可能性があるのか
わからせる為に、列記しなきゃならないってとこ
はっきり言ってダルいっしょ。IDEのサポート無しじゃ書いてられないよ。
現にSTLportとか守ってないしな、駄目じゃん標準ライブラリが守らないんじゃw
まー、こーいうとこはまだ改善の余地ありとか思う。
0263デフォルトの名無しさん
NGNGpublic void finc1() {
try{
} catch (Exception1 e){ ... }
catch (Exception e){ ... }
}
とメソッド内に納めると思うのだが。
0264デフォルトの名無しさん
NGNGExceptionクラスを継承してな。
public class Exception1 extends Exception {
public Exception(){
super("original exception message.");
}
public Exception1(String message){
super(message);
}
}
みたいにな。
0265デフォルトの名無しさん
NGNGimport 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に例外オブジェクトを蓄積してゆく。
そうすると例外情報が上書きによって隠蔽されることもなく、
欲しい例外情報を確実にはき出してくれる。
0266デフォルトの名無しさん
NGNG例えばゼロ除算だが、これの例外処理って必要だろうか？
例外として起こりうる可能性がある以上設けるべきだろうか、
しかし、そもそもまともなコードを書いていればゼロ除算など
ありえない訳で。
ありえないならそもそも例外なんて考えなくていいんじゃないか
みたいな。
また例外というか、コンピュータにおけるエラーって極端に言えば
1、ハードの障害によるもの
2、オペレーターの入力ミスによるもの
この2点しかありえない訳じゃん。(バグを除く)
だったら、この2点だけ対象とした特例的処置を設ければ
それ以外の部分ででエラーというものを意識する必要なんて
別段ない気がするんだよね。
0267デフォルトの名無しさん
NGNGゼロ除算はJavaなら無問題だが。
では新たにそういうものを実装するにはどうすればいいか？
RuntimeExceptionクラスを継承するが
それをなにかしらクラスに組み込まないといけない。
0268デフォルトの名無しさん
NGNGデータの実処理をする部分を
分けて作ればいいじゃん。
だいたい二度手間になるけど。
0269デフォルトの名無しさん
NGNGその二点だけじゃないんだよ。
リリースされて顧客が実際に使ってみて
初めて解るような潜在的バグというものが隠れている。
顧客に気づかれる前にこちらで処理するにはテストケースを
作るのだが。例外があるなら例外を積極的に優先的に使った方がいい。
キャッチされるかも知れない例外はすべてとらえておくべき。
0270デフォルトの名無しさん
NGNG0271デフォルトの名無しさん
NGNGそれ大雑把すぎじゃないの
>>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に格納しなくても連鎖的に保持できるよ。
0272デフォルトの名無しさん
NGNG亀レスだが嘘書くな。特許の三つの条件言ってみろよ
0273デフォルトの名無しさん
NGNGfunc1がexeption1「しか」throwしないなら、ね。
func1〜4それぞれがexeption1〜4の全てをthrowし得るならどうする？
0274デフォルトの名無しさん
NGNGConnection refused
0275デフォルトの名無しさん
NGNGC#ではJavaにあるthrows宣言が存在しない対策をどうとっているのか是非とも教えて遅れ。
0276デフォルトの名無しさん
NGNGthrowsに対応する機能はないよ。ノーガード。
throwsネタは21世紀における新宗教論争だからここでは意見してあげないｗ
C#作者の考えはこんなかんじ
http://www.artima.com/intv/handcuffsP.html
0277デフォルトの名無しさん
NGNG> 例えばゼロ除算だが、これの例外処理って必要だろうか？
必要に決まってんじゃん。
たとえばその例外発生元がプラグインだった場合、
プラグインだけを切り離さなければならない。
全部落ちる必要はないし、その程度でメインのプログラムが落ちたらマヌケだろ。
プラグインじゃなくても、ゼロ除算により「その機能」が
使えないだけで他に影響ない部分もある。
他にも例外発生を分かりやすくするためにログに出力したり、メールで送信する場合も有る。
例外発生してそのまま処理を進ませられない場合でも、例外の処理をすることはある。
ただ、例外を処理するのはいいが、ログに出力しただけで、
例外が発生してない場合と同じ処理を続行するなんてコードを書かないこと。
たとえば>>234のEclipseの自動生成されたtry/catchブロックのようなもの。
例外の基本は上位の関数へ、そのまま/後処理をして/例外の種類を変えて throw。
スタックの最後の部分で例外処理。途中でもみ消したい場合のみ途中で処理。
0278デフォルトの名無しさん
NGNG>ただ、例外を処理するのはいいが、ログに出力しただけで、
>例外が発生してない場合と同じ処理を続行するなんてコードを書かないこと。
理由を聞きたい
0279デフォルトの名無しさん
NGNGまずゼロ除算というのはバグでしか発生しないよね。
そうするとつまり例外機構とは、バグが発生元なる例外も対象としていると考えて良いの？
自分としては、本来は含まれない、含まれないことが望ましいバグというものの為に
リソースを割り振るというのが、なんか引っかかるんだよね。
リリースビルドに、assertマクロをそのまんま残している感じで釈然としない
0280デフォルトの名無しさん
NGNG0281デフォルトの名無しさん
NGNG関数側はどう返事したらいいんだ？
例外か返り値で返すしかないだろ。
返り値をエラー識別子なんぞに使いたくないから、
例外を返すんだ。わかる？
なんでゼロ割の話を特化させてるんだ？
ゼロ割を回避できるロジックが別にあるなら回避して、
無いなら例外だすだろ。普通は。
0282デフォルトの名無しさん
NGNGもしかして<fenv.h>すら知らない人?
C++の例外うんぬん以前に、レベル低すぎて話にならない。
http://www.opengroup.org/onlinepubs/009695399/basedefs/fenv.h.html
まあ除算する前にゼロチェックが有効な局面もあるけどね。
と馬鹿な反応をされないように書いておくよ。(これが例外処理)
0283デフォルトの名無しさん
NGNGC#はバグを減らすことよりも利便性を重視したからthrowsをはずしたんだと思っている。
0284デフォルトの名無しさん
NGNGリンク先読んだか？そんなこと言ってないよ。
0285デフォルトの名無しさん
NGNG彼が本当のことを言わないのはほとんどが
お金のためなんだよ
0286ぽろじょあ ◆niBmDfC40k
NGNG0287デフォルトの名無しさん
NGNG0288ぽろじょあ ◆niBmDfC40k
NGNGぽろじょあ#ぽろっぽ
0289デフォルトの名無しさん
NGNG0291NaN(>>282=>>287)
NGNG0292デフォルトの名無しさん
NGNG,､ｯ.ｨ,
,:'ﾞ ';
(( ﾐ,;:. ,ｯ )))
ﾞ"'''''"ﾞ
もふっ
ﾊ,_,ﾊ
,:' ´∀｀ ';
ﾐ,;:. ,ｯ ﾉﾉ
ﾞ"'''''"ﾞ
ﾎﾟｨﾝ
ﾊ,_,ﾊ ﾎﾟｨﾝ
,: ´∀｀ ';
ﾐ,;:. ,ｯ
ﾞ"'''''"ﾞ
ヽ ｉｌｉ /
- -
ｽﾀｯ
ﾊ,_,ﾊ,
n' ´∀｀,n,
ﾐ,;:. ,ｯ
｀'u゛-u'
ｽﾞﾋﾞｼｯ
ﾊ,_,ﾊ
,:' ´∀｀';9m ＜age！
ﾐ,;.っ ,,ｯ
ι''"ﾞ''u
0293ぽろじょあ ◆niBmDfC40k
NGNG0294ぽろじょあ ◆niBmDfC40k
NGNG0295デフォルトの名無しさん
NGNG0296デフォルトの名無しさん
NGNGいちいち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
0297デフォルトの名無しさん
NGNGC++スレで536が叩かれてます。助けに行ってあげてください。
http://pc5.2ch.net/test/read.cgi/tech/1090180012/536-
0298デフォルトの名無しさん
NGNG期待通りの動きだ。
0299ぽろじょあ ◆niBmDfC40k
NGNG0300デフォルトの名無しさん
NGNG0301デフォルトの名無しさん
NGNG0302デフォルトの名無しさん
NGNG0304デフォルトの名無しさん
NGNG0305デフォルトの名無しさん
NGNGそっから例外が飛んでくるとクラッシュしたりして大変だったね。
最初何が原因かわからなくてさ。
おかげで障害票てんこ盛り。
スレッド頭でキャッチしとけってーの。
スレッド越しの例外投げって危険極まりないね。
0306デフォルトの名無しさん
NGNG勝手に起動したスレッド上で。
全然異常系テストしてねーなってことが判った。
結局そのライブラリは欠陥持ちだってことで、どうしようもないから
ミドルウェアのソース貰って修正したさ。
アホらし。
0307デフォルトの名無しさん
NGNG0308デフォルトの名無しさん
NGNG俺が言いたいのは
例外とスレッドは相性悪いってことだよ。
C++は言語仕様で保障されてないからそれ以後怖くてな、
ミドルウェアの解析までやらされたんだぜ？
例外の仕様がこんなんじゃやってられねーよ。
クソコード書いたミドルウェアのアホ（逃げた）が一番悪いんだが、
不慣れで例外使われるより値返された方がマシだろ。
0309デフォルトの名無しさん
NGNGだけどな、任意の箇所で捕捉できなきゃただの爆弾だよ。
スレッドまたいだだけでクラッシュするのは頭悪いとしか言い様がない。
今回みたいな欠陥ライブラリは、外からじゃどうしようもないだろ。
ソースが参照できたからよかったものの、
無かったらプロジェクト消滅してたぜ？
0310デフォルトの名無しさん
NGNG返された値をチェックしないでスレッドまたぐのとどう違うんですか？
0311デフォルトの名無しさん
NGNG0312デフォルトの名無しさん
NGNG0313デフォルトの名無しさん
NGNG0314デフォルトの名無しさん
NGNG0315デフォルトの名無しさん
NGNG0316デフォルトの名無しさん
NGNGあのライブラリね。
俺もはまったことあるよ。
try・・・catchって書けば普通に動くようになるよ。
0317デフォルトの名無しさん
NGNGバグ対策とバカ対策
http://pc5.2ch.net/test/read.cgi/tech/1067106300/
0318デフォルトの名無しさん
NGNG0319デフォルトの名無しさん
NGNG0320デフォルトの名無しさん
NGNG│ ヽ（ д` ; ）ノ
│ へﾉ /
└→ ω ノ
>
0321デフォルトの名無しさん
NGNG｜ （ *´Д｀）
｜ 人 ヽﾉ､
└―（ ヽ_つ,,,つ
ﾌﾟｽｯ ） ））
（＿_））
0322デフォルトの名無しさん
NGNG例外だからこそ、すぐに問題が発見されたのであって、
エラー原因を返り値で渡し損なっている、
って問題ならもっと発見しにくかったはず。
>>305>>306までの愚痴はまあ分かる。
0323デフォルトの名無しさん
NGNG0324デフォルトの名無しさん
NGNGちゃんとロギングしろよ。
今ならアスペクト指向プログラミングによって
さらにロギングが楽になったぞ。
0325デフォルトの名無しさん
NGNG得体の知れない処理系なんか仕事で使えるかっての
0326デフォルトの名無しさん
NGNG処理系というほどのものじゃないだろ。
JBoss
Spring
Seasar
など、盛りだくさん。
勝手に選べ。
いまならDIというオマケつき。
0327デフォルトの名無しさん
NGNG世の中には「自社開発でない＝得体の知れない、使えない」っつー思考する所がゴマンとあるのさ･･･
0328デフォルトの名無しさん
NGNG0329デフォルトの名無しさん
NGNG0330デフォルトの名無しさん
NGNG0331デフォルトの名無しさん
NGNGどこ?
0332デフォルトの名無しさん
NGNG気になるんなら、検索するか
日本全国の女性と付き合って「ボボ！」って
叫んでみて、ひっぱたかれたらそこだッ！
0333デフォルトの名無しさん
NGNGnewの再配置構文を知らないみたいね。realloc的なものが
ないわけないでしょ。
0334デフォルトの名無しさん
NGNG0335デフォルトの名無しさん
NGNG0336デフォルトの名無しさん
NGNGアスペクト嗜好の資料を読んで
ログに使えると思った奴は素人
0337デフォルトの名無しさん
NGNGこれでcatch all
0338デフォルトの名無しさん
NGNGcatch(Throwable e){
//>>1-337
}
0339デフォルトの名無しさん
NGNGExceptional C++とかぐらい読んでくれないかなあ。
0340デフォルトの名無しさん
NGNG0341デフォルトの名無しさん
NGNG0342デフォルトの名無しさん
NGNG0343デフォルトの名無しさん
NGNG0344デフォルトの名無しさん
NGNGlonghornは例外処理を持つ言語でAPIを全て設計し直しだから、
ちょっと期待しているんだけど。
ただ、MSは基本部分のエンジニアは優秀な人をお金出して呼んでいるけど、
周辺や実装部隊はイマイチだから、とんでも例外設計の可能性もあるなあ。
0345デフォルトの名無しさん
NGNG0346344
NGNG0347デフォルトの名無しさん
NGNG例外キャッチしなくてもコンパイルとおるんじゃないか？
あんまいい作りとは思えんが
0348デフォルトの名無しさん
NGNGAPIの設計はどうなんだろうねえ。
MSDNをちらっと見てみたけど、概説はまだないね。
0349デフォルトの名無しさん
NGNGttp://msdn.microsoft.com/vcsharp/team/language/ask/exceptionspecs/default.aspx
0350デフォルトの名無しさん
05/02/08 17:38:03画面ポップアップMSGにだすことは可能ですか
0351デフォルトの名無しさん
05/02/08 18:58:540352デフォルトの名無しさん
05/02/08 19:24:35デバッグ中のチェックコードはassert
0353デフォルトの名無しさん
05/02/08 23:50:24bool OresamaFunc()
{
try{
if(hogehoge){
return false; // Error
}
// いろんな処理・・・
}catch(...){
//なんか例外出たのでエラーとする
return false
}
return true;
}
これじゃだめ？(´Д｀)
0354デフォルトの名無しさん
05/02/09 00:27:43↓こっちのが幸せな気がしないかい？
void OresamaFunc()
{
if(hogehoge){
throw OresamaError;
}
// いろんな処理・・・
}
0355デフォルトの名無しさん
2005/06/19(日) 23:21:33bool で true false 以外に unknown として例外を返す必要があるとは思わないのか？
OresamaFuncは正常に処理できた実行結果としてtrue falseを返す訳だから
そもそも処理自体が行えなかった場合にはunknown(処理できなかったよ)として
どういう理由で処理できなかったかの例外を関数の呼び出し元に飛ばすべきだろ。
例外発生時に「あぁ、このエラーは漏れの処理ではありうる事なんだYo」と、
呼び出し元が考えるか、「何じゃこりゃ？」と考えるかは
OresamaFancが判断すべき状況じゃないからとりあえず上に例外を投げるんだ。
そしたら、OresamaFancを呼び出した奴が例外を受け取ったときに
適切に判断してくれる(はず)ってのが例外のそもそもの考え方じゃねぇのか？
0356デフォルトの名無しさん
2005/06/19(日) 23:29:17処理が行えたらtrue で行えなかったら false っていうレベルの関数なら
無理に例外投げないで353の実装でもいいと思うけどな。
呼び出し元で
if (OresamaFunc()){
OredayoOre();
}else{
Shoboon();
}
っていう書き方できるし、そっちのほうが漏れ的には好みかな。
例外機構を使うと
try{
OresamaFunc();
OredayoOre();
}catch(OresamaError e){
Shoboonn();
}
見たいな感じで、if文を目の敵にしたのはいいが、
本質的に何も変わらないコードっつーのもなんだかなぁ。
0357デフォルトの名無しさん
2005/06/21(火) 02:12:01B「ミスも少ないですよね」
C「例外はタイピング早いですよね」
A「例外はタイピングしないよ。なあ？」
B「しませんよ、例外は」
0358デフォルトの名無しさん
2005/06/26(日) 00:32:33話になんねぇよ。Unknownって何だよ。意味わかんねぇ。
SQLやりすぎて頭おかしくなった糞コボラ？
BOOLは2値を返す。それが全て。
0359デフォルトの名無しさん
2005/06/26(日) 00:39:31失敗も含めると、結果が２値に収まらないのが問題なんだよ。
0360デフォルトの名無しさん
2005/06/26(日) 00:43:06C言語なみのバカだなｗ
0361デフォルトの名無しさん
2005/06/26(日) 00:44:320362デフォルトの名無しさん
2005/06/26(日) 01:00:100363デフォルトの名無しさん
2005/06/26(日) 02:07:16{
Mekuso();
Mimikuso();
Hanakuso();
}
catch
{
Apoon();
}
0364デフォルトの名無しさん
2005/06/28(火) 03:10:19try..catchしとかないとなぁ
でもやっぱ自分はthrowはしないでつねー
0365デフォルトの名無しさん
2005/07/04(月) 12:21:59try{
処理1();
処理2();
処理3();
処理4();
処理5();
}catch(Exception e){
MessageBox("エラーが発生しました。ゴメンナサイ。理由は " + e);
}
基本処理と例外処理が分離されててみやすいし、例外を見落とすこともない。
でももっと厳密な例外処理が必要になると基本処理と例外処理が入り交じって逆にわかりづらくなるのかな。
経験ないからわからないんだけど。
0366デフォルトの名無しさん
2005/07/04(月) 14:59:430367デフォルトの名無しさん
2005/09/10(土) 13:46:22最初から必要の無いシステムを後からつけたんじゃないの？
例外を含んだコードなんてものは、
例えば、参照をコードの方でｎｕｌｌかどうかﾁｪｯｸして、
ｎｕｌｌだったら例外を返すのではなく、引数を返して、
受け取った方で、上手く行かなかった場合のコードを書くようにしたらそれで良いんだろ。
それとも、例外処理でなければ上手く処理しきれない場合ってあるのか？
知ってる人居たら教えてくれ。
0368デフォルトの名無しさん
2005/09/10(土) 14:10:570369デフォルトの名無しさん
2005/09/10(土) 15:46:58関数という単位で無理やり括るからプログラムが歪になるんだと思う
例外処理も変な制御になる
関数や分岐のネストじゃなくて
フリースタイルに地図のように表現すれば自然に記述できるんじゃないだろうか
おまえらがフローを紙に書くように、だ
0370デフォルトの名無しさん
2005/09/10(土) 15:48:310371デフォルトの名無しさん
2005/09/10(土) 16:00:06A から B を、B から C を呼び出しているとすると
B で C の戻り値をチェックし、A は B の戻り値をチェックする。
エラーの詳細内容 (メッセージ等) はまた別の手段で得る。
というのと
A で例外をキャッチしたら詳細内容も含めて入っている。
というのとでは、どっちが楽だと思う？
>>369
と思う人は、そうやって大盛りスパゲティ作ってればいいと思う。
>おまえらがフローを紙に書くように、だ
フローとてブレークダウンはしている。尤も、今時そんなもん書かないが。
0372デフォルトの名無しさん
2005/09/10(土) 16:24:340373デフォルトの名無しさん
2005/09/10(土) 16:48:03例外の内容は例外オブジェクトをメンバにもつEventArgで通知。
これってやっぱり異端かなあ。
でも楽でいいんだよねえ。VB.NETだと特にイベント扱うの楽だから。
0375名無しさん＠そうだ選挙に行こう
2005/09/11(日) 05:41:56言いたいことはわかる。
グラフ構造で表現できればすっきりするだろうね。
0376マイク ◆yrBrqfF1Ew
2005/09/11(日) 06:49:25無いな。
0377名無しさん＠そうだ選挙に行こう
2005/09/11(日) 12:12:26って方言でなんかエロい言葉なの？
0378名無しさん＠そうだ選挙に行こう
2005/09/11(日) 14:39:05単に>1が消防なだけ。
0379名無しさん＠そうだ選挙に行こう
2005/09/11(日) 16:48:58エラー コードを返したり、グローバル変数の設定したりすることと
同レベルだと思ってはいけません。例外は、それを取り巻くコードの
構造と意味を、根底から覆します。例外は、プログラムの実行時
セマンティックを一時的に繋ぎ変え、通常実行しているコードを迂回し、
こういう状況でなければ決して実行されないコードを動作させます。
例外は、エラー状態を認知させ、プログラムの死という罰則を用いて
その状態を改めようとします。
このように、例外には単純なエラー処理を超えた特性があります。
これらの特性を必要としない、理解しない、あるいは文書化したく
ないなら、例外をスローしてはいけません。
例外以外のエラー処理技法を探してください。
0380デフォルトの名無しさん
2005/09/11(日) 23:53:57山下清画伯だとおもうが
0381デフォルトの名無しさん
2005/09/12(月) 14:02:47福岡とか熊本あたりかな。
メメジョってのは鹿児島だっけ？
0382デフォルトの名無しさん
2005/09/16(金) 02:48:28↓のスレを読めばどんなに偉大な言葉か理解出来るかも。
http://comic6.2ch.net/test/read.cgi/csaloon/1122393817/l50
0383デフォルトの名無しさん
2005/09/20(火) 20:52:02例外は、無くても良いものを後から無駄につけただけ。
0384デフォルトの名無しさん
2005/09/20(火) 20:57:34特にC++の例外機構は欠陥だらけなので。
他の言語だったら大丈夫なケースはあるかと。
0385デフォルトの名無しさん
2005/09/20(火) 22:28:29だから例外をよく理解できない自分は悪くない、ということにしたいのですね。
0386マイク ◆yrBrqfF1Ew
2005/09/21(水) 02:54:51初耳です;)
0387デフォルトの名無しさん
2005/09/21(水) 13:38:250388デフォルトの名無しさん
2005/09/21(水) 13:41:24>その一方で EH でいくつかの意図的でない深刻な結果が生じるということも
>疑いません。しかし、筆者は C++ 規格の作成者らに先見の明がないと言っ
>て責めるのではなく、効果的な例外処理を設計して実装することがどれだけ
>難しいかということを心に留めています。
遠まわしに欠陥だらけと言ってる。
0389デフォルトの名無しさん
2005/09/21(水) 14:11:51・型が弱い。関数プロトタイプに許容する例外クラス木を列挙指定できない。
>>388
C++にも欠陥はあるが、例外処理そのものが難しいことも忘れてはいけない。
と言っているように読める。
0390デフォルトの名無しさん
2005/09/22(木) 04:02:43> ・型が弱い。関数プロトタイプに許容する例外クラス木を列挙指定できない。
これは関数の例外仕様のこと？ int f() throw exception; // ←コレ？
例外仕様が無いことは欠陥とは言い切れないよ。
0391デフォルトの名無しさん
2005/09/22(木) 06:09:22後発のC#では削除されている。
0392デフォルトの名無しさん
2005/09/22(木) 07:35:26どのあたりが欠陥なのか簡単に説明してくれるかな？
0393デフォルトの名無しさん
2005/09/22(木) 08:52:54そこでContinuation渡しですよ。
0394デフォルトの名無しさん
2005/09/26(月) 21:41:54実現イメージは出ないけど、continuationみたいなのは結構いいかもしんない
Javaのexceptionより、system call の返り値のerrnoを見るほうが好きな俺は
比較的賛成だ
うまく例外処理コードを通常処理コードと分離（隠蔽）出来るといいんだがなあ・・
0395デフォルトの名無しさん
2005/10/23(日) 12:26:21C#のthrows削除は欠陥仕様。
先発のJavaの利点を殺している。
0396デフォルトの名無しさん
2005/10/23(日) 13:25:49throwsを書かないようにするのが、今の流れだと思っていたが。
0397デフォルトの名無しさん
2005/10/23(日) 14:08:38細かくチェックさせることもできる。
0398デフォルトの名無しさん
2005/10/23(日) 18:49:49意味ねーじゃんｗ
ちゃんと例外設計しろよｗ
0399396
2005/10/23(日) 20:47:20Hibernate 3.x からは unchecked例外になった。
Springの例外も、すべて RuntimeException を継承している。
詳しくは Expert One-On-One J2EE Design and Development を参照してくれ。
0400ハーピィ
2005/10/23(日) 23:11:310401デフォルトの名無しさん
2005/10/27(木) 00:45:02の違いが解っていない人多いよね
C++もこの違いを意識して書けば、これほど便利なものは無いのに
先ずはExceptionの設計をしないで使ってる事が問題
0402デフォルトの名無しさん
2005/10/31(月) 14:53:590403デフォルトの名無しさん
2005/11/01(火) 00:16:270404デフォルトの名無しさん
2005/11/03(木) 00:24:15格闘してる開発部隊がいたの思い出した
テストとか見ていて、ちょっと気の毒だった
0405デフォルトの名無しさん
2005/11/03(木) 02:55:06無責任な例外送出は迷惑極まりない。>>379でほとんど言われてしまったけど。
■ このスレッドは過去ログ倉庫に格納されています