回答編集履歴
3
typo
test
CHANGED
@@ -52,7 +52,7 @@
|
|
52
52
|
|
53
53
|
でも、発生するエラーを予想していない以上ちゃんと回復することは無理ではないでしょうか?
|
54
54
|
|
55
|
-
最悪、大元のtry-catchが原因でプログラムが異常終了さえできなくなってハマったりもします
|
55
|
+
最悪、大元のtry-catchが原因でプログラムが異常終了さえできなくなってハマったりもしますので、かなり難しいです。
|
56
56
|
|
57
57
|
|
58
58
|
|
2
追記分へのコメント
test
CHANGED
@@ -33,3 +33,33 @@
|
|
33
33
|
|
34
34
|
|
35
35
|
と書いてる私はC++erです。でも、バリバリOOPしてますのでOOP的な共通事項について回答させて頂きました。
|
36
|
+
|
37
|
+
---
|
38
|
+
|
39
|
+
|
40
|
+
|
41
|
+
【追記へのコメントです】
|
42
|
+
|
43
|
+
> 設計の際に例外が想定できてなくて、デプロイ後、お客様側で画面が真っ白になるみたいの
|
44
|
+
|
45
|
+
> (Javaとかだと回避できる方法があるんでしょうか・・)を避けるためにできる工夫があれば
|
46
|
+
|
47
|
+
> 教えていただきたいです。
|
48
|
+
|
49
|
+
「想定していない例外(エラー)」が起きることを想定して(笑)、プログラムするってことですね。
|
50
|
+
|
51
|
+
できるだけ大元でtry-catchしておくとか?
|
52
|
+
|
53
|
+
でも、発生するエラーを予想していない以上ちゃんと回復することは無理ではないでしょうか?
|
54
|
+
|
55
|
+
最悪、大元のtry-catchが原因でプログラムが異常終了さえできなくなってハマったりもしますが。
|
56
|
+
|
57
|
+
|
58
|
+
|
59
|
+
ですので、理想は「想定していないエラー」があってはいけないのだと思います。
|
60
|
+
|
61
|
+
例外の場合、これが非常に難しいのですよね。奥深いところで発生する例外まで調べるのってなかなか。
|
62
|
+
|
63
|
+
だから、できるだけ理想に近づけるよう努力するしかないです。
|
64
|
+
|
65
|
+
なので、例外を使う明確なメリットが無い時まで例外を使うのはよろしくないと思います。
|
1
日本語のミスとリスト項目の修正
test
CHANGED
@@ -12,7 +12,7 @@
|
|
12
12
|
|
13
13
|
|
14
14
|
|
15
|
-
ちなみに、例外はエラーを返却する方法の1つです。もう1つは戻り値や参照パラメータで返却する
|
15
|
+
ちなみに、例外はエラーを返却する方法の1つです。もう1つの方法は戻り値や参照パラメータで返却することです。それぞれ一長一短があるのでどちらを使うのか良く検討するべきです。
|
16
16
|
|
17
17
|
原則は戻り値で返却し、特定のケースで例外を使うのが妥当と思います。
|
18
18
|
|
@@ -20,13 +20,13 @@
|
|
20
20
|
|
21
21
|
さて、私自身は、パッと思いつく限り、下記のようなケースで例外を投げます。
|
22
22
|
|
23
|
-
リリース後もassertionさせる時。
|
23
|
+
0. リリース後もassertionさせる時。
|
24
24
|
|
25
|
-
エラーの種類ごとに分けてエラー・リカバリさせたい時。
|
25
|
+
0. エラーの種類ごとに分けてエラー・リカバリさせたい時。
|
26
26
|
|
27
|
-
複数の関数呼び出しに対して、纏めてエラー・リカバリさせたい時。
|
27
|
+
0. 複数の関数呼び出しに対して、纏めてエラー・リカバリさせたい時。
|
28
28
|
|
29
|
-
多重に関数呼び出しされている奥のほうで発生したエラーを遠くの呼び出し元でエラー・リカバリさせたい時。
|
29
|
+
0. 多重に関数呼び出しされている奥のほうで発生したエラーを遠くの呼び出し元でエラー・リカバリさせたい時。
|
30
30
|
|
31
31
|
(後、C++では例外を投げる処理は重いので、頻繁に動作する正常系処理では例外を投げないようにしています。)
|
32
32
|
|