ボボボーボ・ボクは例外処理が嫌いなんだな
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
NGNG何の例外が飛んでくるかわからないクラスなんて怖くて使えない
そもそも例外処理って大域ジャンプだろ、
そんなもの怖くて使えねーよ
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
■ このスレッドは過去ログ倉庫に格納されています