感想

うーん。やはり設計段階から、

ユーザーがどんな誤った入力をするか

を場合分けして、対策を打っとくの大事だよなあ。

詳細

見出しとしては、

1. 誤った入力への防御

2. アサーション

3. エラー処理テクニック

4. 例外

5. バリケードによるエラーの被害の囲い込み

6. デバッグエイド

7. 製品コードに防御的なプログラミングをどれくらい残すか

8. 防御的プログラミングに対する防御

9. 参考資料

10. まとめ

てな感じ。

開発フェーズと製品フェーズでの対処の違い

といった誤入力に関する対処方法通じて、防御的プログラミングについて説明してる章。

たしかに、過去にテストで参画した大手ECサイトの入力画面で、
NAME（全角英字）
って表示してるのに、試しに日本語で、

ひらがな、カタカナ、半角カタカナ、半角英字、数字、記号のどれで入力しても、
OKボタンを押して次の画面に進めて、
登録できてしまう
👉（全角英字）の意味なし！！！！！

なんてザラにあったもんな。
開発かセルフチェック時に、

こんな入力をする可能性もある

と想定してないことが原因。
こんな入力を許していたら、全角英語しかないはずのカラムにあらゆる文字が存在して、フィルタもクエリも複雑になり、データ屋さん泣かせなDBになってしまう、、、。

こんな時の対処としては、

自分で指定したキャラクタタイプかどうかをtype ofとかで判定
↓
全角英字以外であれば、エラーメッセージを表示して、先に進めないようにコードを組み込む

で済んじゃう。

例外処理のところで、

//GASの例
try{
 本処理
} catch(e) {
 例外時の処理
} finally {
 完了時の処理
}

で、本来は、本処理と例外処理までで十分な場合も多いのに、
構文の意味を理解していないからなのか、finallyまで必ず書く人
や、
switch文（VBAのSelect Case Elseみたいなもの。）

//GAS
switch(){
  case1:
  case2:
  …
 default:
} 

で場合分けの考慮が漏れているのに、defaultまで必ず書く人

finallyとかdefaultって

以外は全部

と同じだから、意識して使わないと

想定外の処理を無自覚に実行してから涙目

になってた人も多かったなあ、、、とうっすら思い出してしまった。
教科書とかでそう書いているから、無意識だと思わず使っちゃうアルアルなんだけど、、、💦

なので、普段は、

//GASの例
try{
 本処理
} catch(e) {
 例外時の処理
} 

までしか使わないし、
そんなに場合分けも多くならないようにルーチン分けしてるから、

if (条件１){
　条件１の処理
} else if(条件２){
　条件２の処理
} else{
　条件１条件２以外の処理
}

って感じでそもそもSwitch文を使わずにif文で済ませちゃう。
こっちの方が、

else 　：　 以外の場合　

ではっきりわかるし。

他にも、

よく設計していたACCESSのデータベースの簡単すぎる例だと、
ACCESSで入力フォームを作る場合、フォームの元になるテーブルのデータ型で

• 電話番号なら　半角の数字だけ

• メールアドレスならば、半角英数字と記号だけ

• 入力フォームに、入力規則を表示して、規則に沿った入力を促す

で、他の文字タイプで入力できないようにしちゃう。

何でもかんでも

自由に入力できた方がいい

と、自由を追い求めたがる人もいたけど、

電話番号やメールアドレスにまで自由を求めない
（電話番号入力欄に漢数字とかひらがなとか打ちたい人ってどのくらいいますか？）
し、
データベースの管理が面倒になる
だけだし、、、。
そうやっとくと、

• データベース管理の負担が軽減される

• エラーを想定したコードを打たなくて済む

• 入力する側も入力方法がわかるから迷わなくて済む

ので、双方にとって

負担が少なく、わかりやすいシンプルな設計で、コードも少なく実現

できてた。

まとめ

（コードを追うのも大事だけど）
💃コード以外で、もっと簡単に誤操作や誤入力を防ぐ方法がないかを探す🕺

最近は、この本について感想を書いてます。

初めて読む人、数年ぶりに読み返す人、座右の書で答え探しで読む人など
人によって感想も発見も全然違うと思う。

で書いているとおり、
つらつら徒然に感想書いているだけだけど、
世界中の一流プログラマが一度は読んでいると言われるバイブル的な本らしい。

興味が沸いたら是非是非、読んでみてね。