回答編集履歴
2
異常系処理との差について記載を追加
test
CHANGED
|
@@ -31,3 +31,29 @@
|
|
|
31
31
|
と書くわけです。コメントと比較して良いところは、結合テスト中にインタフェースミスが
|
|
32
32
|
|
|
33
33
|
はっきりと分かるところです。 NullPointerException だと、「サブルーチン作成側の考慮漏れによるバグ」なのか「担当者間のインタフェースミス」なのか言い争いになるところを assert を書くことによって「担当者間のインタフェースミス」であることが確定するところにメリットがあります。
|
|
34
|
+
|
|
35
|
+
|
|
36
|
+
|
|
37
|
+
一方で assert を書くくらいならそのチェックを正式コードとして入れてはどうかという説もあるかと思います。しかし、内部モジュールのインタフェースミスと Exception という正規の異常系処理ロジックを混在させることは、可読性をさげるとともに、デバッグを難しくします。
|
|
38
|
+
|
|
39
|
+
|
|
40
|
+
|
|
41
|
+
```java
|
|
42
|
+
|
|
43
|
+
public abc(String x, String y) {
|
|
44
|
+
|
|
45
|
+
if (x == null) {
|
|
46
|
+
|
|
47
|
+
throw Excpetion("予想外のエラーが発生しました（関数 abc の第一引数に null が渡されました）");
|
|
48
|
+
|
|
49
|
+
}
|
|
50
|
+
|
|
51
|
+
if (y == null) {
|
|
52
|
+
|
|
53
|
+
throw Excpetion("予想外のエラーが発生しました（関数 abc の第二引数に null が渡されました）");
|
|
54
|
+
|
|
55
|
+
}
|
|
56
|
+
|
|
57
|
+
```
|
|
58
|
+
|
|
59
|
+
というようなコーディングを多く見かけるわけですが、これだけだと、この Exception が発生したときにエンドユーザが入力をミスしたのか、システム障害でI/O に失敗したのか、インタフェースミスのバグなのかがコードから判定がつかないわけです。これを assert で書いておけば、インタフェースミスのバグであることが確定でき、可読性を向上させるとともに、トラブルシューティングを簡単にすることが可能です。
|
1
誤解を招く表現を修正
test
CHANGED
|
@@ -30,4 +30,4 @@
|
|
|
30
30
|
|
|
31
31
|
と書くわけです。コメントと比較して良いところは、結合テスト中にインタフェースミスが
|
|
32
32
|
|
|
33
|
-
はっきりと分かるところです。 NullPointerException だと、「考慮漏れ」なのか「
|
|
33
|
+
はっきりと分かるところです。 NullPointerException だと、「サブルーチン作成側の考慮漏れによるバグ」なのか「担当者間のインタフェースミス」なのか言い争いになるところを assert を書くことによって「担当者間のインタフェースミス」であることが確定するところにメリットがあります。
|