全メソッドにtry〜catch〜finally〜

当然の処理だよな

ぶび厨のネタスレか……

好きにしていいよ。

俺はできる限り、全メソッドにtry〜catch〜の処理を入れる。
イベントで取ることもできるのだが、如何せん処理が重い。
try〜catch〜に書くほうが、メモリは食うだろが断然早い。

>>3
意味不明。

>>1
各メソッドの責務次第。
例外なんぞ呼び元の範疇ならば処理しないし、隠蔽するなら投げなおさないし。

もともとの VB.netスレの極論の欧州は馬鹿丸出しすぎて。
イベント関数なりで最終処理すればいいとか、Application自身の例外部分でとか。
中国人並のモラルに思えた、ごみ掃除は誰かがやるって。

投げなおしは基本中の基本。
関数A
　関数B
　　関数C
　　Cで例外→スロー
　Bで例外→スロー
Aで例外→エラーマッサージ

美しい！

>>5
B、Cで投げなおしだけなら、そこにはtry〜catch〜いらなくね？

スレタイにも>>1にもVB.NETとは書いてないのに
VB.NET限定の話題しかされてないのは何故？

よくしらない俺はfinallyだからJavaかと思った

>>7
元の揉め事がvb.netスレに昨日の話題だから。

てっきりC#かとおｍ（ry

Application.ThreadExceptionで処理すればいいみたいなこと書いてたけど、そーすっと
プログラムそこで終わんね？
必死で書き換えてみて(俺も全メソッドでtry〜してた、再スローはしてなかったけど)愕然としちまったんだけど

アホか

>>11
それは結局ワトソンでて終わるよりマシ程度に思うけどね。
適切に処理されない最終的なバグがそこにつかまるから。

tryをnew
finallyをdeleteに変えればいいじゃないかな
ガベージなんたらの幻想に気づくだろ

>>11
処理継続可能(予測可能)な例外 → メソッド内でTry-Catch、個別対応
予測不可能な例外 → ThreadExceptionで受けてアプリ終了

誰が全部まとめて処理っていってんだよ。
個別に処理できないものはって何度も書かれてるのに
そういうことにしたいみたいだな。
それから、例外をラップすることは勿論あるが、
じゃああらゆるメソッドでラップするかっていうと
そんなわけがない。
ていうか意味がない。

機能なりモジュールなり役割なり、
何らかの境界となる所でラップすることが多いだろ

>>5
そのBでの投げ直しがなんのためなのかが重要なわけで
意味のない投げ直しは意味がない

ごみ掃除は誰かがやるって誰がいってんだよ

>>11
全メソッドでキャッチして再スローはしないって
一体キャッチした後どう処理してんだ？

またやるの(;´Д`)

俺は今日も戦うぜ。

BのスローはAへの通知だ。

結構再スローしろと書いているサイトも多い品。

>>19
しない
強いて言えばconsole.writeline(ex.tostring)でデバッグしやすくするだけ
要はプログラム止めないためにキャッチしてるだけだから

>>23
はげどう
全く同じ

例外飲み込んでも良いけど
どうしてその例外を無視して良いのか
コメントにはきちんと残しとけよ。

catch (IOException e) {
// めんどくさいので無視
}

PHPでは全てcatchするのが当たり間ウェ

error_reporting = E_ALL & ~E_NOTICE
もあたりまゑ？

ちがうだろ。
くるしまぎれにしか過ぎないない。
びっくりしたわｗ

例外無視して処理続行して大丈夫なのか…？

>>30
大丈夫だよ

>>26 の例とかだと処理続行するには致命的な問題が出そうなもんだが？

まあ本当に致命的なエラー出て止まることもあるが、いずれにせよ止まるなら、動き続ける
可能性があるならそっちを選ぶ
大抵はヌル参照とかで大抵無視しても何とか動くし
もちろんDBの処理はちゃんとロールバックしたりSQLログに書き出したりしてる

処理続行不能な致命的例外なら処理続行はバグだろ？

止まってしまうことが問題と言うより、
整合とれてない状態で動き続けるのが怖い。

>>33みたいにテキトーなことやって、何となく動いてるシステムが無数にある現実

ヌル参照で大抵無視しても動き続ける
ｵｲｵｲ

それで処理続行してデータとか壊すんだよ。
ロールバックしてるっていうが、そこで例外にならなきゃロールバックやらないだろ…

>>33 は例外として投げすてられるべきだ

catch(>>33)
{
　　　(・ω・`);
}

On Error Resume Next

>>33
全米が落ちた。

なぁ、そこまで例外処理を全域に設置するなら
これはもうIDEでガーってやってしまうべき解決領域だと思うんだ

とりあえず、前スレのコレはちゃんと読んでから発言しような。
同じことぶり返してるぞ。

http://pc8.2ch.net/test/read.cgi/tech/1155292844/838-993

>>33
ちゃんとバグ取ろうな。

例外なんて、予想できるものじゃない。

全メソッドにtry〜catch〜で例外処理を書いたほうが、
構造に芸術性を感じないか？

感じない

>>46
俺もそう思う。
そもそも、イベントで拾うだけなのは手を抜いてるって言うか、
創造性が無いというか。

所詮２ｃｈ。
クリエイティブな連中はいないってことだろうね。

>>46
俺は C++ で同様のことをやってるけど、
必要に応じて throw をマクロで弄って __FILE__ と __LINE__ をログ出力させたりしてる。
こうするとどういう呼び出し階層上で例外が発生したのかが簡単にログに残せて便利。

>>49
>必要に応じて
どういう必要ですか？同じ処理なら一箇所で十分。

>どういう呼び出し階層上で例外が発生したのかが簡単に
イベントで拾っても同じことが出来ます。

>>50
俺が知らないだけでなんかいい方法があんの？
イベントで拾ってどうやってコールスタックを知るの？
そもそも"イベント"かなんかを俺が勘違いしてる？

PHPでどうやってイベント拾うのか教えてくれ

StackTrace辿って行けば、どこでcatchしても発生元はわかるじゃん。
C++でできるのか、は知らんけど

>>53
あー、お前が言ってんのは .NEET の話か。
C++ じゃ変態系の技でも使わん限り無理。

>54
Managed C++, C++/CLI
どっちも変態系だというつっこみはなしで。

>>55
変態かどうかはさておいて、そいつら名前にこそ C++ ってついてるけど C++ じゃないから、それ。
仮にそいつらが C++ だってんなら Java も C++ だとするべき、それぐらい違うから。

Java も C++ だとするべき
Java も C++ だとするべき
Java も C++ だとするべき
Java も C++ だとするべき
Java も C++ だとするべき

結論はどうなったんだよ

>>58
むしろ、Managed�C++,�C++/CLI が Java 。

昨日先輩が言ってたけど、
全メソッド、プロパティ、ファンクションありとあらゆるものにtry-catch-finally the rock come back to XXXを入れるのが正しいプログラミングだそうです。

そんなプロレスネタ誰もわからんぞ。

構造化例外ってのをちゃんと理解していたら全メソッドにtry-catchを入れるなんて発想は無いと思うのだが。
まるで昔よくやっていた、戻り値としてエラーコードを返すような関数言語の意識が抜けていないのではないか？

>>44

try-catch-as-catch-can-finally

>>62
そのクソの役にも立たない五択はいいから

関数言語ねえ

ごたくはいらんから全部キャッチしろとよ。

>>61
>>60のどこがプロレスネタなんだよｗｗｗ

>>44

今日引き継いだソースが全メソッドにtry-catch-finally。
もうダメポ…('A`)

当然の処理だよな
そこに発注したい

ちなみにキャッチして何やってるの？
気になるなぁ

>>70
ちなみにそのソースはどの程度の粒度でメソッドを書いてるんだ？
ダメポと絶望できるくらいしょうもない「try」を例示してくれ。

sub aho()

Try

　dim a as object

//くそながいコード

Catch ex
End Try

End Sub
　　

VB厨の大半は全部キャッチして握りつぶしやがるからな。

すべての、メソッドに、On Error Resume Next を、書き加える!!

それがっっっ　VB厨のジャスティス!!!

もういいよ。

決着は前スレで既についてる。
全メソッドにtry-catch-finallyとか言ってるやつは何も根拠がない。

>>78
あぁ、君が必死だった人なんですかww

>>79
前スレ読んでまともな意見いってみろよ

だから、全メソッドにtry-catch-finally　はネタだよ。
釣られすぎ

try-catch-finallyに根拠なんて要らないだろが

>>82
根拠がない＝全メソッドに必要ない
ってことにならないか？

C++でtry-catch-finallyいれまくったんだけど全然キャッチしねーよ

バカが連呼してる「前スレ」ってなぁに？

ＭＦＣのダイアログアプリで構造化例外処理をする場合どこを__tryで囲えばいいの？

>>83
だから、チームや会社のルールだろ。
会社が書けといってるのに、根拠がないから拒否するのはルール違反。
懲戒処分ものだ。

　　　　　　　　　　　 ,,,-‐''"~　　　　　~ﾞヽ､,,----､.,,,,_
　　　　　　　　　.,,r''~　　　　　　　　　　　　 ﾞヽ、　　　`ヽ､
　　　　　　　　／　　　　　　　　　　　　　　　　 ﾞi,　　　　　`ヽ、
　　　　　　　/　　　　　　　　　　　　　　　　　　　i,　　　　　　 ﾞi,
~~'''''‐-＝ /　　　　　　　　　　　　　　　　　　　　 i　　　　　　　 ﾞ､
　　　　　　i'　　　　　　　　　　　　　;ﾍ,　　　　 .:.::::i':::..　　　　　　　ﾞ,
　　　　　　i　　　　　 　 　 　 　 　 /./　　　　 .:.::::/.:.:.:..　　　　　　　i
　　 　 　 ﾉ　　　 　 　 　 　 　 　 / /　　 　 .:::::::/:::.:.:.:.:.　　　　　　　i
　　　　／　　　　　　　　　　　　/./　　.:.:.:.:.:.:／,;.:.:.:.:._____ 　 　 （<ヽ!}　　
　 　 / 　　　　　　　　　　　　i^ヾ'i:.:.:.:.:.::::::;　'　　.:.:.:;'､;:;:;;;;:;;ﾞi　. 　ﾞiヽ＼ 　おらおら
　　/ 　 　 　 　 　 　　　..:....:.:ﾞ､_　ﾞ:、:::::／　　,,,,,....-i'ﾞi;====ﾖ　 　 ,!　＼＼ 　全メソッドにtry-catch-finally書けや
　 /;;;;i　　　　　　　　　　　　.:.:.:.:ﾞi　｀ヽ､　　:.:..:.:.:.:.:.:! ''ﾞi;:;:;:;:;;!　,r‐'ﾞﾞ'' ,! ヽ､>
　ﾒ;;;;;;;i,　　　　　　　　　　　.:.:.:.:.:.:.:、　 ﾞ'ｰ‐-､,,;---､ゞ　ﾞ''''''i'／　　 /
/:::i;;;;;;;ヽ、　　　　　　　　　.:.:.:.:.:.:.:.:.ヾ、　　　　　　　 ﾞ　　 　 ﾞ` 　 ,ノ
::::::ヽ;;;;;;;;;＼　　　　　　　.:.:.:.:.:.:.:.:.:,ｲ.:.:.ﾞ''ｰ-､,,___　　　　　 　,;. ､　,ｿ
:::::::::::＼;;;;;;;;;`ヽ､,_　　　.:.:.:.:.:.:.:.:.ノ 〉,.:.:.:.:.:.:.:.:.:.:.:ﾞi｀　　 　,:;'' i;　ヾi′
:::::::::::::::ヽ､;;;;;;;;;;;;;;;;;ﾞ''‐─--‐‐/　,{;;;;ヽ､.:.:.:.:.:.:.:.:.:|　　　 '"　 ;:　 ﾞ|
::::::::::::::::::::::`ヽ-､;;;;;＿＿,,,,,／　 /＼;;;;;;;;;`'''─----|　　　　　 ;: 　 !
::::::::::::::::::::::::::::::::::::::::::::::::::::ノ　　 i:::::::::ﾞヽ､;;;;;;;;;;;;;;;;|　　 　 　 ;;!　,!

そんな理不尽なルールがまかり通る会社なら
さっさと転職した方が身のため。

>>85
ログ読め。解らない馬鹿は帰れ。

>>87
そんな事言ったらなんでもありになるだろ。
会社のルールとしかいえない時点で確たる根拠がないと言われてもしょうがないな。

>>89>>90
ルールを理不尽と言って守らないのは、
「殺人してはダメ」ということを理不尽と言って守らないのと同じ。
集団で何かをする場合はルールが必要で、
それを守らないことに対して厳しい処分があることはしょうがない。

>>91あほ
Aというやりかたは正しいか？
に対してうちの会社はAだ
これは会社のルールだ
だから誰がなんと言おうと正しい
ルールを守らないやつは最悪だ。

いつの間にルールを守るのが正しいか否かの議論になったんだよ。

>>91ていうかお前ねたじゃなくてマジで言ってるだろｗ

バカと議論することがいかに無益かを的確に表すスレだな。

殺人とかあほな例を出してくるのは、
前スレのアインシュタイン様か？

>>91
そのルールが「でも、ムカつく奴なら殺してもおk」ってなルールなら
改正させるべく動かなければいかんだろ。
なにがあるべき姿でどーあるべきか議論せず、ただ与えられたルールを
そのまま鵜呑みするようなやつは技術者にあらず。
だが逆に、改正されていないルールを無闇に破るようなやつは人にあらず。

>>94が全て。世の中トップダウンで大体おｋ

バカを説得したいのか、自分が納得する答えが返ってくるとおもってるのか
議論を吹っかけてるほうも目的意識がないんじゃないか？

…それが何かまずいのか？

>>96
＞そのルールが「でも、ムカつく奴なら殺してもおk」ってなルールなら
＞改正させるべく動かなければいかんだろ。
ルールがそうなら、殺してもOKだろ？
殺人自体100%の悪じゃない。
ちゅーか、日本は現在に至るまで、
誰もが何があっても人を殺したらダメだという法律になったことはない。

ルールを変えたい場合お前みたいな一般人がただ吼えるのではなく、
変える立場になればよい。
お前の言葉はまさに中二病ｗｗｗ

とにかく、俺の会社ほどのところが使っているルールだ。
守るのがデファクトスタンダード。

>>100
バカ必死だね（´-ω-｀）

残念だが、お前の会社がどれほどだか伝わってこない。
全メソッドにtry-catch-finallyを付けなければならないことはわかったが。

アインシュタインがどうのというのはわからないけど・・・
ほんとうにデファクトスタンダードを確立されている
会社だとお見受けします。就職活動の参考にしたいので、是非
社名をご教示いただけますでしょうか。

話がそれたから元気になってきたな。

バーカバーカ

>>103
数年前に合併した外資系です。

よし、みんなで社名と言語を晒して、
どっちか投票しよう。

俺は株式会社AZマラキックスというところでVB.NETやってます。
全メソッドとは言わないけど、ほとんどのメソッドにtry-catch-finally書かされています。

finallyとかあんま簡単に使わないほうが良い気がするけどな。

>108
逆？

>>106,107
基本的なルール（匿名掲示板）を理解しておらず、失礼しました。以後は、
地に足がついた就職活動を続けて行くことにいたします。今回は、誠に望
外の計らいを頂き、ありがとうございます。

おお、わかってくれました？
前スレにもありましたが、アメリカでも推奨されている全メソッドtry-catch-finallyを認めない、
がんこなアホなエンジニアを晒すスレなのです。
なので、無理に個人情報を晒すように誘うことはやめましょう。

>>108簡単にって、明らかに使うべくして使うもので、
簡単に使ってしまうという状況が分からない。

もうあきた。

そんなことよりも、4ch見てみろよ

>>109
あぁ、考えようによっちゃそうなんかもな。
つい最近までPythonはcatchかfinallyのどっちかしか使えなかった希ガス。

>>111
前スレ知らないんでアメリカが推奨しているというソースがどこにあるか教えてほしい。

>>111
スレ読み返しててみましたけれども、たしかに、こ
れとっいた内容は見かりません。すいませんが、一体
全体、どこにアメリカ・・・て書いてあるのか、その
部分を教えてください。

>>103=>>117
「空気の読めない間抜けはレスをするな。」
これは2ch黎明期より原則となっております。もちろん間抜けとはあなたのことです。
お吊りの際にはLANケーブルの使用が推奨されています。

空には綺麗な星がいっぱい出てるからゆっくり眺めてみろよ。
気持ちがとっても落ち着くぜ？
読書して日曜を過ごしたが、try-catch-finallyは全メソッドで使うべきと書いてあった。
メンテを考えると大変だろうが、動作の安定性を考えろとのことだそうだ。
馬券は出走取り消しで変換だし、
鹿島アントラーズのせいで、TOTOは外すし、散々な日曜日だ。、

チッ。
ンなこと言ったって、try-catch-finallyは全部に入れる。
コレするしか無いだろ。
なんで理解できないかな？
めっぽう反論は糞だし、
てま掛けてプログラミングしろよな。

やだ

>>119
Application.ThreadExceptionで全ての例外が拾えるのに、
なぜtry-catch-finallyを全メソッドに書くことが安定性に繋がるのか説明してくれよ。

この答えを今まで誰ひとりまともな解答してないんだよ。
それでも尚言うか？

もっと自然に。

全メソッドにtry-catch-finallyがあっても拾えない例外がある。
Application.ThreadExceptionは全ての例外が拾える。

さあ、どうあるべきよ？

ざんねーん

彼女に投げた愛のメッセージがthrowされますた
だれか

>>124
全メソッド個別にエラー処理する。
それ以外をイベントでフックする

>>124
同じ例外処理はイベントで一括フックする。
それ以外をメソッド内で個別にエラー処理する。

そもそも個別にやらないといけないような例外処理なんてほとんど無い。

例外処理の内容が全部同じなら、Application.ThreadExceptionだけでよい。

>>129
Application.ThreadExceptionイベントがない言語はどうやるんだ？

　　　　　　　　　　　　　　 ,　　　　　 ,
　　.／ ￣/　￣　　/　＿|＿_　＿__|＿
　　　 ―/　　　　 /　　 ｜／ 　　/|
　 　 ＿/　　＿／　　　 |　　＿／｜
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 /＼＿＿_／ヽ
　　　 (.｀ヽ(｀＞ 、　　　　　　　　　　　　　　　　　　　　　　／''''''　　　'''''':::::＼
　　 　 `'＜｀ゝr'ﾌ＼　　　　　　　　　　　　　　　　　＋　　|（●）,　　　､（●）､.:|　＋
　 ⊂ｺ二Lﾌ^´　 ノ, ／⌒)　　　　　　　　　　　　　　　　　|　　,,,ﾉ(､_, )ヽ､,,　.::::|
　　⊂l二L7_　/　-ゝ-')´　　　　　　　　 　　　　　　　.+　|　　 ｀-=ﾆ=- '　.::::::|　+
　　　　　　 ＼_　　､__,.ｲ＼　　　　　　　　　　　＋　　　　 ＼　　 ｀ﾆﾆ´　 .:::／　　　　+
　　　　　　　　(T＿_ノ　　 Tヽ　　　　　　　 , -r'⌒!￣ `":::7ヽ.｀- ､　　　./|
　　　　　　　　　ヽ¬.　　　/　ﾉ`ｰ-､ﾍ<ｰ1´|　 ヽ　| :::::::::::::ﾄ、 ＼　(　　./ヽ
　　　　　　　　　　＼l__,.／　　 　 　 i　l.ヽ!　|　　　.| ::::::::::::::l ヽ 　 ｀７ｰ.､‐'´ |＼-､
　　＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿__　 ＿＿
　│二│三│四│二│三│四│二│三│四│◎│◎│◎│伍│｜伍｜
　│萬│萬│萬│萬│萬│萬│萬│萬│萬│◎│◎│◎│萬│｜萬｜

　　　/　　/　　　　　　　　ノ
　　 /　　/　　──　　─┼─
　　　　／　　　　　　　　／
　　　　　　　　　　　　　　　　　　　　　　　　　　　　 　 /＼＿＿_／ヽ　　　　　　 .
　　　　　　　　　　　　　　　　　　　　　　　　 　 　 　／''''''　　　''''''::::::＼（　　　) ノ
　　　　　　　　　　　　　　　　　　　 　 　 　 　 +　　|（●）,　　　､（●）､.:(　(　）　＋
　　　　　　　　　　　　　　　　　　　　　　　　　　　　| 　　,,／⌒ヽー､　.:::ﾉ　).　
　　　　　　　　　　　　　　　　　　　 　　 　 　 　 +　| ,.-' 　　ヽ 〉､ヽ＝＝ ﾉ　
　　　　　　　　　　　　　　　　　　　　　　　＋　　 　 ／　__⌒〉ﾉ./ﾕ`J’／　　 　 +
　　　　　　　　　　　　　　　　　　　　 　 　 　/￣ ／　　/ ￣´iﾉ､　　./|
　　　　　　　　　　　　　　　　　　　　　　　　レイ　　 ./ﾄ、 ＼　(　　./ヽ
　　　　　　　　　　　　　　　　　　　　　　　 （　　　　_ﾉl ヽ 　 ｀７ｰ.､‐'´ |＼-､

　　/ﾆﾆ/l　　/ﾆﾆ/ﾆﾆ/l　./ﾆﾆ/ﾆﾆ/l　/ﾆﾆ/ﾆﾆ/l　./ﾆﾆ/ﾆﾆ/l　./ﾆﾆ/ﾆﾆ/l　/ﾆﾆ/ﾆﾆ/l　
　　|::::::::| |.　 |::::::::|::::::::| |　|::::::::|::::::::| |　|::::::::|::::::::| |　|::::::::|::::::::| |　|::::::::|::::::::| |　|::::::::|::::::::| |　
　　|::::::::|/...　|::::::::|::::::::|/　|::::::::|::::::::|/　.|::::::::|::::::::|/　|::::::::|::::::::|/　.|::::::::|::::::::|/　|::::::::|::::::::|/

―┼┐　　 イ　. 干　―┼┐ 　 　 |_|_　 ,　
　 / .｜　 　木　 田　　../ . |　　 　 |┬　田
／　　|＿| . ｜　 土　／　　|＿| 　./｜ .'十
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 /＼＿＿_／ヽ
　　　 (.｀ヽ(｀＞ 、　　　　　　　　　　　　　　　　　　　　　 ／''''''　　　'''''':::::::＼
　　 　 `'＜｀ゝr'ﾌ＼　　　　　　　　　　　　 　 　 　 ＋ 　 |（●）,　　　､（●）､.:|　＋
　 ⊂ｺ二Lﾌ^´　 ノ, ／⌒)　　　　　　 　 　 　 　 　 　 　 |　　,,,ﾉ(､_, )ヽ､,,　.::::|
　　⊂l二L7_　/　-ゝ-')´　　　　　　　　 　　　　　　　.+　|　　 ｀-=ﾆ=- '　.:::::::|　+　.
　　　　　　 ＼_　　､__,.ｲ＼　　　　　　　　　　　＋　　　　 ＼　　 ｀ﾆﾆ´　 .:::／　　　　+
　　　　　　　　(T＿_ノ　　 Tヽ　　　　　　　 , -r'⌒!￣ `":::7ヽ.｀- ､　　　./|　　.
　　　　　　　　　ヽ¬.　　　/　ﾉ`ｰ-､ﾍ<ｰ1´|　 ヽ　| :::::::::::::ﾄ、 ＼　(　　./ヽ
　　　　　　　　　　＼l__,.／　　 　 　 i　l.ヽ!　|　　　.| ::::::::::::::l ヽ 　 ｀７ｰ.､‐'´ |＼-､
　. 　＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　｜一｜九│一│九│一│九│　 │　 │　 │　 │　 │　 │　 │　 │
　　｜萬｜萬│索│索│筒│筒│東│南│西│北│　 │中｜發│發│
　　└─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴―┴─┘

最上位のメソッドでもしくはそれに近いメソッドでキャッチすればよかろう

そうか、例外はコストがしゃれにならんから全て潰していたんだが・・・・・

ユースケース上に出てくる例外はtry〜で取り、それなりの処理を行うべき
それ以外のシステム例外は最上位メソッドかそれに近いところでキャッチ

main関数に入れておきゃいいじゃん

VBだと、>>128>>129 で良いようだが、他の言語だと随分勝手が違うよな。
ま、言語異存も激しいけど、真剣に悩むほどのことでもあるまい。

>>91
>>100

あたまわるっ

>>139
クークックックックッｗｗｗ

>>68
rock

>>141
プロレスじゃなくて音楽じゃねーかよ、ﾊﾞｶ

ちょｗｗｗなにこの頭悪いスレｗｗｗ

結論はすぐわかるだろ　常識的に考えて

C++の演算子オーバーロードしたことないの？
（↑の意味わかります？）

教えてくれよ。
PHPでどうやってイベントだけで例外処理やるんだぜ？

例外なんてほんとの例外だけだろ
それ以外のキャッチできるような例外は事前にソフト側で防御すべきだ

Exception発生は極力避けないと無駄な処理に時間取られるとおもう

on error gotoは偉大だった