新しいページを作ってまとめるほどではないけれどもスレでちょこちょこっと話題になった技術的なお話をメモする所です。
有益な情報がたらたらと流れていってしまっている気がしたので作りました。スレでの役に立つFAQなんかをどんどん書き足していって下さい。
初歩的なことでも遠慮せずに気軽に書き込めたらと思います。
本スレ・避難所より抜粋（一部編集あり）
593 以下、名無しにかわりましてVIPがお送りします [sage] Date:2009/06/25(木) 10:07:05.32 ID:kkNfJZRU0
・例外が投げられうる場所でtry～catchを使っておかないとプログラム全体が落ちる
これが最も重大なtry～catchの使いどころ
catchの中でリソースリークを防ぐコードを書いたり、メッセージを表示するのは、意味的には二次的なものになるだろう
596 以下、名無しにかわりましてVIPがお送りします [sage] Date:2009/06/25(木) 10:17:12.63 ID:Bbxi1UV40
.NetFrameworkだとエラー発生時にcatchしないとCLRが自動的に検出したりする
そういう時に必ずエラーで落ちたりするのでエラーが発生しかねない箇所にはエラーを貼る
後は実際の業務でも、同じExceptionでも層ごとに業務の独自例外を投げたりするので
そういう時は便利
597 以下、名無しにかわりましてVIPがお送りします [sage] Date:2009/06/25(木) 10:33:47.30 ID:kkNfJZRU0
明らかに使い方が間違っていることに起因する例外ー(.NETだとArgumentException等)、起こる＝バグなので、処理せずにおくのが(デバッグの都合上)好ましい~
一方で、正しく使っていても起こりうる例外(ファイルアクセスやネットワーク系等)は、起こることが予め想定されているのだから、例外処理をせずに落ちる方がバグ
例外の投げ方については2つの使い方があり、
1. は通常の使い方、というか本来の形。ライブラリのメソッドが提供する例外の投げ方と同じだな 2. は特定の処理の内部でのみ使う形。単にいちいちreturnするのを省略しているだけなので、決してトラップを忘れて外に出してはならない
724 名前：以下、VIPにかわりましてパー速民がお送りします[] 投稿日：2009/06/25(木) 11:14:05.13 ID:Tv/kdEM0
＞実際の開発の現場では、2. のような場合も一般的に例外が使われているのでしょうか？
決して「一般的」では無いが、㌧でもない設計のコードを直さなきゃならん場合とかに、急避難的なパッチとして使うケースがある。
無論、それに起因したバグってのが有り得る（そしてそれは発見し難い）ので決して絶対に口が裂けても推奨は出来ないが、デスマーチから逃れる為の劇薬ともなる。
＞catch&tryで記述した方がコードの見通しが格段によくなる場合がありそうです
実際に多々ある。関数の途中でreturn;とか書く香具師が跡を絶たない理由だな。
そうすることで「本来の主要な処理」を「処理順序通り」に「間に長々としたエラー処理を挟むことなく」書くことが出来るからな。
それは、何処から何処までがエラー処理なのか、とか考えなくて済むので見通しが良い。
720 名前：以下、VIPにかわりましてパー速民がお送りします[] 投稿日：2009/06/25(木) 10:22:31.41 ID:Tv/kdEM0
「研究分野とは関係無いんだけどプログラムとして書かなきゃならないエラー処理」ってのがあるでそ？
それが「例外」なんで、其処で処理するのに書く。
例えば指定したファイルが開けなかった場合・・・はやりすぎだけど、アルゴリズム検証用に画像サイズが２の冪数でなきゃならないプログラムを書いたとする。
なのに画像サイズが２の冪数でないことが判明した時とかにthrowで投げるとか。
同じく検証用にモノクロで検証しようって時にカラー画像が指定されていることが判明したらthrow投げるとか。
で、その全体をtryで囲っておいて、catchで「検証用なんで、読み込める画像には制限があるます」とか表示させて終了したりする。
同じように、作業用メモリーを確保しようとしたら失敗したとか、ファイルを読み込もうとしたら途中で止まった（多分途中で切れていた）とか、とにかくもうどうにも出来ん時にも例外を投げる。
最大の使いどころは、画像処理部分だけの関数を作った時（そしてライブラリー化して使いまわそうとした時）で、画像処理部分でエラーが出ても、それをどう処理するかをアプリケーションに任せたい場合。エラーが出たらthrowで例外を投げるようにする。
この場合は必ずしも「エラーが出たら即終了」が最善ではないから、アプリケーションが何か特別な処理をしたいはずだ。その時はアプリケーション側でtry～catchを使う。
738 名前：以下、VIPにかわりましてパー速民がお送りします[] 投稿日：2009/06/25(木) 16:58:14.85 ID:Tv/kdEM0
＞例外のcatchをもってチェックの代替にしても良かったりするのだろうか
良い。ものすごいのになると、ダイアログでキャンセルを押されたら例外を投げる、というライブラリー群も存在するぐらいだ。
スレ内で何人か「例外というのは想定の範囲外を処理するもの」と言っているが、これは昔（例外を含んだオブジェクト指向設計の普及以前）からのプロの考え方で、「予測可能な全てに対処する（＝エラー処理を完璧にする）のがプロだ」という正しい考え方に基づいている。
それ自体は今でも正しいが、其処から派生して、「例外」は予測不能な事態に対処する為のものであり、予測可能ならあらかじめifでチェックするべし、という方向に進んでしまう傾向にある。
新しく現れた「例外」の扱い方に慣れてないわけだな。
そうではなく、「例外」は「順調に進むはずである処理の流れ」を妨げる時に使うものだ。
日本語で言うなら、「～～をし、次に～～をし、そして～～をする。但し～～の場合は例外とする」という感じ。
そういう意味で「例外」ってのは適切な名前。
先の「ダイアログでキャンセルを押されたら例外」で言うと、「ユーザーが指定したファイルを開き、こねくり回して、上書きする関数である。但しユーザーが途中でキャンセルした場合は例外とする」ってことになるわけだ。
如何なる例外で処理が中断されたかを呼び出し側が判別し、それに適切な処理（例えばユーザーにアラートを出すとか）を行えばいい。