回答編集履歴
2
追伸の為
test
CHANGED
|
@@ -71,3 +71,19 @@
|
|
|
71
71
|
例えば、ユーザーが入力した値を、その後加工して、加工後の結果をDB登録するのであれば、DB登録前でしかチェックしようがないですよね。
|
|
72
72
|
|
|
73
73
|
この場合は、ユーザーが入力する時に想定されるエラーチェックを事前にしておき、さらにDB登録前に加工後のエラーチェックをするというロジックであれば、抜けもれを防げますよね。
|
|
74
|
+
|
|
75
|
+
|
|
76
|
+
|
|
77
|
+
ところで、質問者さんが記述されているロジックですが、このロジックそのものも、関数化できそうですね。
|
|
78
|
+
|
|
79
|
+
名前でなくても、そもそも暗号化してデータベースへ格納する行為は同じなので、
|
|
80
|
+
|
|
81
|
+
登録用関数に、それぞれのチェック関数を組み込んで、標準化出来ますよね。
|
|
82
|
+
|
|
83
|
+
記述されているロジックであれば、入力時の想定されるエラーチェック１、DBからあらかじめ登録されている名前を取得際の、DB接続エラーや、そもそもDBにあった場合のチェック処理2、取得した名前を暗号化する際に考えられるチェック処理3と細かくチェックしていきます。
|
|
84
|
+
|
|
85
|
+
そこで素通りしてしまう事の怖さを考えると、その都度チェックするが、一番ですね。
|
|
86
|
+
|
|
87
|
+
色々開発していかれると分かりますが、素通りしてしまうと、一体どこのエラーであるのか、切り分けが出来ず、バグがバグを呼ぶ原因となります。
|
|
88
|
+
|
|
89
|
+
自分を守るという意味においても、都度チェックを細かく細かくするというのを心がけるべきかと思いますね。
|
1
追記の為
test
CHANGED
|
@@ -38,7 +38,7 @@
|
|
|
38
38
|
|
|
39
39
|
|
|
40
40
|
|
|
41
|
-
というのは、関数化出来ていないから美しくないのであって、エラーチェックは、イレギュラーケースも含め考えられるエラーを二重にも三重にもするべきものです。
|
|
41
|
+
というのは、関数化出来ていないから美しくないのであって、エラーチェックは、イレギュラーケースも含め考えられるエラーを二重にも三重にもチェックするべきものです。
|
|
42
42
|
|
|
43
43
|
そして、関数化してあるチェック処理を呼び出すだけだからこそ、バグに強い強固なプログラムが出来ます。
|
|
44
44
|
|
|
@@ -57,3 +57,17 @@
|
|
|
57
57
|
|
|
58
58
|
|
|
59
59
|
このような流れとなります。
|
|
60
|
+
|
|
61
|
+
|
|
62
|
+
|
|
63
|
+
また、どこでこのチェック処理をやるべきなのか？を考えながら書いて見てください。
|
|
64
|
+
|
|
65
|
+
例えば、入力した直後の方が良いのか、それともDBの仕様として全体に対してチェックするべき物なのか？
|
|
66
|
+
|
|
67
|
+
|
|
68
|
+
|
|
69
|
+
どこでチェックするべきなのか？を考える事により、実は１度で良い処理を２度書いてしまったり、抜けもれが発生しにくくなります。
|
|
70
|
+
|
|
71
|
+
例えば、ユーザーが入力した値を、その後加工して、加工後の結果をDB登録するのであれば、DB登録前でしかチェックしようがないですよね。
|
|
72
|
+
|
|
73
|
+
この場合は、ユーザーが入力する時に想定されるエラーチェックを事前にしておき、さらにDB登録前に加工後のエラーチェックをするというロジックであれば、抜けもれを防げますよね。
|