はじめに
設計の時点でエラーハンドリングの意識はできていますか？
読みやすくてバグを拾いやすいコーディングをすることで、レビューもしやすくなりますし、非機能要件の考慮もできます。ここでは、そんなことについて触れています。
駆け出しの人に向けた記事になっていますので、優しいマサカリはいつでもお願いします。
何がおいしいの？
これで実装するととりあえず
- セキュリティ
- 保守性
- 可読性
- テスト性
- 例外処理の正確さ
が担保できると思います。
内容
処理に入る前に異常値はすべて弾くという記述法です。
メリットとしては、
①テストしやすい（正常系以外が拾いやすい）
②処理に余分な例外がなくなり読みやすい（例外処理がわかりやすい）
③レビューしやすい（設計書に照らし合わせやすい）
などがあると思います。
コード例
あくまで一例ですが、このようなコーディングができます。
method A(int num, String str){
//セッション情報の確認
セッション確認
//num値の確認
if(num == null) {エラー処理1};//nullはだめ
if(num <= 0){エラー処理2};//0以下はだめ
if(num > 3){エラー処理3};//1,2,3以外だめ
//num値OK、str値の確認
if(str == null){エラー処理4};//nullはだめ
if(str.equal("")){エラー処理5};//空文字はだめ
//str値OK、処理
if(num == 1){
//処理１
}else if(num == 2){
//処理２
}
}
処理に入るころには入力値系の例外はすべて拾えている
といった寸法です
#おわり
このようなコードがのちに書かれることを想定して設計することで、後工程でもメリットが得られます。
詳細設計レベルでは落とし込みができますが、基本設計レベルでは粒度の問題でできないので、コーディング規約で縛るのもアリかもしれませんね。