以前、例外を期待するソースは行儀が悪いと書いたのですが、私的にはRDBの制約違反を期待するソースも行儀が悪いと思うのです。
顧客マスターなどのマスター類の主キーはユニークです。(例外もありますが...無視)
Code 名前
010 Ognac
020 Wankuma
のデータがあるとき
020 ABC をInsertすると重複違反例外が起こります。例外を受けて、重複メッセージを出したりしているのを見ると、いいのかなぁと思う。
これは、一度 CODE=020 の存在Checkをして、更新処理か追加処理かの分岐をすべきだと考えます。
業務ロジックからみてもこの方が筋が通っています。例外の結果でエラーしたり更新に分岐するのは不合理です。
外部キー違反も例外を期待するのでなく、事前チェックすべきだと考えています。
RDBの制約違反はコトスが高い処理ですし、例外を期待するコーディングはロジックを考え尽くしているとは思えないのです。
勿論反論はあります。「RDBの機能として制約が存在しており、データ矛盾を指摘する機能なので積極的に機能を利用すべきだ」と指摘されたりします。
確かに機能を利用するとコーディング量が減り見通しもよくなるような錯覚をします。
そうでしょうか、例外を期待してのコーディングは楽なのですが、ロジック考察力が劣化するし、ソースの品質も劣化しているように見えます。
RDBの制約は、子データが存在するのに、親データを消したときの例外発生などのデータ矛盾の防止に用いるのが本筋です。
市販本のサンプルやTips集はポイントレッスンなので局所的に正解ですが、そのままコーディング標準などに取り入れるとスキル低下をもたらす遠因になります。
サンプルを理解しないでコピペで使うプログラマが悪いのか指導者が悪いのか....個人のモチベーションなのかなぁ..向き不向きなのかなぁ...よくわからん<--ナゲヤリな俺。
-追- 一部内容が一方的な見方で間違ってました。お詫びします。コメント参照してください。