メモ - 例外

Advertisement

階層分離開発における例外設計

階層分離開発では深い層で発生した例外は、それより浅い全ての層を通過する。つまり、どの層でもキャッチすることができるということである。
層を跨(また)いで受け渡されるデータは、うまく設計しないと後々システムに混乱をもたらす。一度設計が破綻すると、むりやりツギハギをあてるか、または多大な修正コストを費やして丸く収めなければならない。

階層分離開発では、サービス層で発生した"サービス例外"はプレゼンテーション層でキャッチするように統一することで、比較的綺麗な構造になる。ビジネスロジックも多大な例外処理を考慮する必要が激減する。例外発生時の動作も変更に強くなる。

例外処理の統一

テストのカバレッジ向上作業を行っていて気づいたのだが、例外に対する処理が開発者によって異なっている。

ある人は、想定外の例外(データ不備によるNullPointerExceptionなど)をすべてキャッチし、サービス層の例外を再throwしている。
try{
    // 略
}catch(Exception e){
    throw new ServiceLayerException(e);
}

また別の人は、想定外のケースに対応したりしなかったりしている。要するに、自分のコードですら統一されていない。理由はわからないが、おそらく思いつくままにコーディングした結果だろう。
String id = dao.getId();
if(id == null){
    throw new ServiceLayerException("id not found");
}

String name = dao.getName(id);
// 上記のような処理は無し。
例外戦略はコーディング基準同様、プロジェクトで統一されていなければならない。
バラバラに実装された例外処理の統一化は、リスクを伴う多大なコストがかかる。

Advertisement

ショートカット

634トップページ
このカテゴリのトップページに戻る
634ラボ

サイト検索

Google

Web サイト内

Y!ログール