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