常に例外を取るべきか取らないべきか

Question

下記のソースは、データベースへ接続するときに例外が発生した場合、例外処理が発生するものです。

try {

//接続
$dsn = "dbname=aaaa;host=localhost";
$user = "root";
$password = "";
$dbh = new PDO($dsn, $user, $password);
$dbh->query("set names utf8");

print "接続しました。";
//接続解除
$dbh = null;

} catch(exception $e) {
    print "ただいま障害が発生しており大変ご迷惑おかけしております。".mb_convert_encoding($e->getMessage(),'UTF-8','JIS,ASCII,CP51932,SJIS-win');
	exit();
}

たまたまネットサーフィンしているときに、データベースに接続する際のことを指南しているサイトを見つけ閲覧していたところ下記のソースが記述してありました。

try {
  $pdo = new PDO('mysql:dbname=phpdb;host=127.0.0.1', 'root', '1234', array(PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION));
  $pdo->query('SET NAMES utf8');

  $stmt = $pdo->query('SELECT * FROM address WHERE no >= 10 AND no <= 20');
  while ($data = $stmt->fetch(PDO::FETCH_ASSOC)) {
    echo '<p>' . $data['no'] . ':' . $data['name'] . "</p>\n";
  }
} catch (PDOException $e) {
  exit($e->getMessage());
}

$pdo = null;

http://www.php-labo.net/tutorial/class/pdo.html

PDOの第４引数に何かを指定できること自体、ネットサーフィンをして初めて知りました。第４引数にDB接続中に発生したエラーをどのように通知するかを指定できるATTR_ERRMODEとERRMODE_EXCEPTIONを指定することで
"接続時"以外のエラーが発生したときも一律に例外を投げることが出来るのでソースの記述が短くなります。
ここで疑問ですが、先述の技巧と接続時のエラーのみ例外を投げ、それ以外は、条件分岐などで個別にエラーの対処をするのは、どちらが適当であると思いますか。
ソースが短くなる以外に、何か利点はありますか。

Answer 1

お邪魔します。

難しい問題ですね。意見の分かれるところだと思いますが。

説明のために、異常が発生するケースを分類してみましょう。
異常が発生するケース、というのは大まかに言って

1. ハードの異常やネットワーク異常など、アプリケーションでは回復不能なエラー
2. コーディングミスや設計ミスによる不具合（アサーション例外を含める）
3. 処理の順序や仕様上想定されない操作によって発生する回復可能な例外

このくらいに分類できるのではないか、と思います。

例外というのは何かしらアプリケーションに起きている問題を、開発者やユーザに知らせるための機構であると考えることができます。
アプリケーションの動作のしようがないからアプリケーションを落としてしまうとか、次に登録ボタンを押したときは大丈夫かもしれないから放置で知らんぷりとか、そういうのは設計としてお粗末ですよね。
ロギングを行って異常を回復するための情報を保守開発者に対して残す(ロギングをトリガにメールが飛ぶ機構などもよくありますね)、ユーザに異常を伝えてシステムの管理者や保守を行っている人間に連絡を取るよう促す(=ようするにメッセージの表示、ということになるのかな)、など誰かに異常発生を伝えるためのトリガとなるイベントなんです。

そう考えると異常発生時の挙動の設計がまずあるべきで、1.ならこのエラーはユーザに伝えても仕方がないなとか、いやこれはシステムダウンしてるしエラーページ表示しないとなとか、3.なら先にこのページを開いてこの操作をしてもらわないといけないからユーザにメッセージを表示しようとか、それぞれ例外が発生する状況で要求される動作が自然と決まっていくはずです。

異常を誰にどう伝えるかが決まると、異常発生を捕捉し対応するログ出力やメッセージの表示やページ遷移の処理を記述する必要が出てきます。例外の種類(=異常の原因)によって行うべき処理が異なってくると、一つのcatch節でより抽象的な例外をハンドリングしてコーディングするのはあまり格好が良くなく、どのコードが原因で異常が発生したのかをとらえにくくなってしまいます。

少し話はずれますが、避けることができる例外を発生させる、処理の実現方法として例外を使用するやり方は、混乱を招くのでよくない、とされています。
賛否両論ありますが、先にテーブルのデータを調べておけば発生しない例外、例えばUPDATEするレコードがない時でもあえて一度UPDATEをかけて例外が発生したらインサートに切り替える、などという書き方もありますが、更新を実行して失敗するという無駄な処理(データベース上でもトランザクションが発生し、行やテーブルのロックも起こるでしょう)が実行され、その分処理が遅くなったり、処理によってはデッドロックの危険性を高めたりもするので、先にSELECTをかけてから結果をみてUPDATEをかけるかINSERTをかけるか判断する、といった実装をすることが多いです。(DBサーバ因ってはmergeなんてのがあらかじめ用意されてたりもしますが)

また、2.のアサーション例外はハンドリングするべきでない、というかテストで出ないように潰すべきものですね。バグの原因の特定がしやすいように例外にメッセージを出すのが良いやり方です。例外で落ちると、直さないといけないことがわかりやすくていいです。
デバッグ起動以外では投げられないようにしておくのも、少し黒いですが現実的な考えですね。

少し質問の内容とはズレたところがあったかもしれませんが、例外処理・エラーハンドリングに対する全般的な考え方について思うところを記載してみました。

長々と書きましたが、結論としては、すべて一か所でハンドリングするかそうでないかは、想定される異常と、それぞれの異常発生時にどのような回復処理や通知処理を行うか、また、その処理でどれだけの処理をするか(=SQLを実行するか)、という設計による、というのが回答です。

以上です、参考になりましたら幸いです。

追伸

自分は本職がjava書きなもので、java言語だと例外処理についてこういう議論がなされてるよ、という参考リンクを張っておきます。質問の内容からするとぐっと深いところですが、例外マスターになれるかも?!
参考まで。
Java のチェック例外と非チェック例外の考察まとめ