質問するログイン新規登録

質問編集履歴

1

解決した旨を追記

2018/08/31 14:11

投稿

Kaguya_2324
Kaguya_2324

スコア9

title CHANGED
File without changes
body CHANGED
@@ -44,4 +44,26 @@
44
44
  # 質問
45
45
  このような場合、特に触らずに例外を投げるのと先に弾くのだと、どちらのほうが良いのでしょうか。今までC++を書いていたので、予測でき回避できる例外はプログラム側で弾いたほうがいいのではと思っているのですが、言語側が詳細なエラーを投げてくれるならそのままにしたほうがいいのかなというような気もして迷っている次第です。Rubyの慣習としてこうするよ、だったり例外とreturn nilはこう使い分けるよ、だったりという意見をいただければ幸いです。
46
46
 
47
- 長文をお読みいただきありがとうございました。よろしくお願いします。
47
+ 長文をお読みいただきありがとうございました。よろしくお願いします。
48
+
49
+ # 解決しました!
50
+ いくつもの回答を参考にさせていただいたので、質問への追記という形で回答の要約と私が取った解決法を共有させていただきます。今回、
51
+
52
+ - Rubyでは、例外はそんなに怖がらなくて大丈夫
53
+ - むしろ、nilを返すほうが何が起こったのかわからなくてまずい
54
+ - 例外を投げる場合は、プログラムのバグなのかユーザー側の問題なのかわかるようにする (たとえば、例外クラスを作る)
55
+ - 想定内の入力によって投げられた例外でプログラムが終了するのを避ける。例外をキャッチして、エラーメッセージを出す
56
+ - 操作をする前に例外が発生することが予見できるなら、先に判別して例外を投げる
57
+ - (異常な値を返すにせよ例外を投げるにせよ) 妥当性の確認は仕様に従い、穴がないように作る
58
+
59
+ というアドバイスをいただきました。
60
+
61
+ 今回は期待する入力は数字二個の間に演算子、という仕様を想定していたので、
62
+
63
+ - 入力が変なものじゃないかを正規表現で確認する。変なものだったら独自エラークラスを作成して投げる
64
+ - ゼロ除算が発生するときにはreturn nilを避け、例外を投げる。計算前に、raise ZeroDivisionError if b == 0を行う
65
+ - 例外を入出力を行っているメソッド (私の場合はトップレベルでした) で捕捉し、種別に合ったエラーメッセージを出す
66
+
67
+ といった実装にしようと思います。
68
+
69
+ 最後に、回答いただいた皆様にお礼を申し上げて締めさせていただきます。皆様にご回答いただいたおかげで知見がとても広がりました。また機会があればよろしくお願いします。ありがとうございました!