Q&A
otnさん、回答ありがとうございます。
> 例外でプログラムが終了することを避ける。
なるほど…！例外を投げておしまいにするか、return nilしてエラーメッセージを出すかという二択に勝手に囚われてしまっていたので、例外を投げた上で自前でエラーメッセージを出すというのは盲点でした。
発生している問題
Ruby(2.5.1)の勉強の一環として、計算機を作ってみようと思いました。空白区切りで数値と演算子を与え、答えを出力する簡単なものです。
in
11 + 1
out
12
足し算、引き算、掛け算に関しては特に詰まることなく実装できたのですが、第二数が0となった場合の割り算についてどのように実装するべきか戸惑いました。
考えたこと
特に別の処理をしない
最初に考えたのは、特に他の演算と別の処理を行わないことです。第二数に0が指定された場合、ZeroDivisionErrorが発生してプログラムは停止します。
calc.rb
1def calc(a, op, b) 2 case op 3 # 他演算子の処理、中略 4 when "/" 5 return a / b 6 end 7end
in
11 / 0
out
1divided by 0 (ZeroDivisionError)
先に判別し、nilを返す
次に考えたのは、先に第二数が0であるかどうか判別し、0であった場合はnilを返すことです。nilが返ってきた場合は呼び出し元でエラーメッセージを出力することを想定しています。
calc.rb
1 when "/" 2 if b == 0 then return nil end 3 return a / b 4 end
in
11 / 0
out
1ゼロで割ることは出来ません
質問
このような場合、特に触らずに例外を投げるのと先に弾くのだと、どちらのほうが良いのでしょうか。今までC++を書いていたので、予測でき回避できる例外はプログラム側で弾いたほうがいいのではと思っているのですが、言語側が詳細なエラーを投げてくれるならそのままにしたほうがいいのかなというような気もして迷っている次第です。Rubyの慣習としてこうするよ、だったり例外とreturn nilはこう使い分けるよ、だったりという意見をいただければ幸いです。
長文をお読みいただきありがとうございました。よろしくお願いします。
解決しました！
いくつもの回答を参考にさせていただいたので、質問への追記という形で回答の要約と私が取った解決法を共有させていただきます。今回、
- Rubyでは、例外はそんなに怖がらなくて大丈夫
- むしろ、nilを返すほうが何が起こったのかわからなくてまずい
- 例外を投げる場合は、プログラムのバグなのかユーザー側の問題なのかわかるようにする (たとえば、例外クラスを作る)
- 想定内の入力によって投げられた例外でプログラムが終了するのを避ける。例外をキャッチして、エラーメッセージを出す
- 操作をする前に例外が発生することが予見できるなら、先に判別して例外を投げる
- (異常な値を返すにせよ例外を投げるにせよ) 妥当性の確認は仕様に従い、穴がないように作る
というアドバイスをいただきました。
今回は期待する入力は数字二個の間に演算子、という仕様を想定していたので、
- 入力が変なものじゃないかを正規表現で確認する。変なものだったら独自エラークラスを作成して投げる
- ゼロ除算が発生するときにはreturn nilを避け、例外を投げる。計算前に、raise ZeroDivisionError if b == 0を行う
- 例外を入出力を行っているメソッド (私の場合はトップレベルでした) で捕捉し、種別に合ったエラーメッセージを出す
といった実装にしようと思います。
最後に、回答いただいた皆様にお礼を申し上げて締めさせていただきます。皆様にご回答いただいたおかげで知見がとても広がりました。また機会があればよろしくお願いします。ありがとうございました！
回答6件
0
ベストアンサー
計算機の目的・機能と「特に触らずに例外を投げるのと先に弾くのだと、どちらのほうが良いのでしょうか。」という二者択一とう制約下なら、「例外を投げる」という選択を私はします。
計算機が状態を持たないならば、case by caseを事前に検知して捌くことにあまりメリットを感じないからです。
二者択一の制約を外した場合は「事前に判断して、自分で例外を発行する」ということをします。
速度面の要件を満たせるなら、この策が防御力と対応力が高いからです。
ポイントは「状態を持つか否か」です。（計算機でいうなら電卓のメモリ機能のような）
例外の良い点は、特段自分で実装しなくともオン・デマンド（on demand）で異常を自発的に通知してくれることですよね。自分が油断しててもプログラムがフォローしてくれる。防御力が高いです。
ただし、どこで何が起きたかお知らせしてくれるだけ。お知らせに応じた対応は自分でやらないといけないのですが、そこまで油断していると、後で問題が起きたりします。例外に応じて、適切な状態に戻したり、変更したりする必要がでてくるわけです。すると例外によってcase by caseで対応が必要なってきちゃいます。だったら、先にわかるものは先に片付けておこうと思うわけで、事前判断しようと考えます。そうすれば状態を戻すようなことを考えずに済むから。例外だけだとちょっと足りないんですよね。
（昔はJavaのDBにおけるConnectionのCloseし忘れで、DBの最大接続数食いつぶすとかありましたな。）
方や事前判断で戻り値を返すとすると、呼び出し元で異常の種類を知りたいなんてことになった場合、戻り値でしかお知らせできないので、0=正常、1は警告、2は…なんて話なり、情報が足りない文字情報も欲しいなんてなれば戻り値はクラスでなんて話にもなっちゃってインターフェイスの仕様変更で面倒です。影響範囲は全部修正・テストなんてことになってコストかかっちゃいます。この点は例外の機構が助かります。正常ケースには影響を及ぼさず、別途エラークラスを作る（takahasimさんのやつ）ことをすれば、case by caseを的確に必要かつ十分な情報を添えて通知することが可能です。なので戻り値返しじゃなくて、例外を使いたくなるんですよね。例外は通例ではない例外への対応力を上げるのにとても便利なんです。
（int型の戻り値の関数で、値ごとに意味はなんだ？定数か？なんだ直書きだし定数と意味ちげぇとか。）
ということで、「事前に判断して、自分で例外を発行する」という手を私は取ります。
質問文のcalcは状態を持たないので例外で一択ですが、
双方得意・不得意があるので、合わせ技で良いところを生かすのが旨い手だと思います。
計算機がメモリ機能を持つようなら、合わせ技の出番。そうなったら考えてみてください。
投稿2018/08/29 16:38
編集2018/08/29 16:46
総合スコア804
0
計算機のプログラムであれば、0の入力はあり得ることなので、ゼロ除算は想定内であると言う仕様にするのが妥当でしょう。つまり、例外でプログラムが終了することを避ける。
ゼロ除算である旨のメッセージを出す方法としては、
案1：除数がゼロであるかチェックしてから除算を行う
案2：そのまま計算して、ゼロ除算の例外を投げてもらい、ユーザインタフェースを行う階層でそれをキャッチして、メッセージを出す
案1は、質問のようにメソッドの階層がある場合に、役割分担が難しくなります。
案2が良いと思います。
例外のキャッチ方法は、リファレンスの例外処理 を参照。
投稿2018/08/29 16:22
総合スコア86301
0
一文で
コーディングの勉強ならどっちでもいいですが、普通に電卓の実装を書くのなら例外をキャッチすべきです。
言い訳を考えてみる
自前でバリデーションをかけるのは例外を自前で実装することと同じで、ライブラリに実装済みのものがあるのに自分でもう一回実装していることに相当します。
今はゼロだけを考えていますが、文字を入力されたらどんなバリデーションを書きますか？
例えば、
1 / a
1 / 1 1
上のものはどうバリデーションしますか？
考えうるパターンを網羅しますか？
1 / ( 1 - 1 )
1 / (
はどうします？
逆に、上の考慮が必要ないケース、数字２つで真ん中に記号と確定していて、拡張は絶対にありえないのならバリデーションをかけても良いことになります。
さらに、「入力された数字同士の演算をすること」が目的ではなく、「特定のフォーマットの入力に対する加工」として捉えるのなら入力された時点で正規表現による正当性確認をすべきです。これなら例えば4桁までの数字同士の計算を簡単に強制させることができます。
一般にバリデーションを事前にかけるべきパターンとしては、例えばインジェクション対策のエスケープとかに思い至ります。
ただ、電卓にそれが必要かは不明ですし、やるにしても、ライブラリを使いますね。
投稿2018/08/29 22:39
総合スコア8562
mkgreiさん、回答ありがとうございます。
> 1 / ( 1 - 1 )
な、なるほど… 数字2つで真ん中に記号と思い込んでしまっていたのですが、確かにそのような入力が来たらb == 0では弾ききれませんね…。
> 正規表現による正当性確認
自分にはなかった視点です。a, bをInteger()して確認したつもりになっていました。
自前で確認するのは例外を実装し直しているのと同じ、というご意見が突き刺さりました。例外が発生しうる状況を自分で網羅出来ない限りは例外をキャッチしたほうが確実ですね。自分で仕様をちゃんと決めて、その穴を塞げるように頑張ります。
0
いろんな意味で「例外」はあるわけで、それは足し算、引き算、掛け算の実装に置いてもあったはずです。
- 記号やアルファベット、漢字が入力として使われていた場合
* 1 + + 3など、普通に演算できない順序で入力が行なわれた場合
たぶんこのあたりはcalcの呼び出し前に対応していたかと思いますが、この辺をどのように処理するかによって、０で除算した場合の処理も変わってくるかと思います。
また、例外を投げるにしても、ZeroDivisionErrorをそのまま投げるか、あるいは別途エラークラスを作ってそれを投げるか、という選択もあります。
結局は、アプリケーションまたはライブラリ全体の、例外の扱いを設計する必要があるのでした。
投稿2018/08/29 15:33
総合スコア1877
takahashimさん、回答ありがとうございます。
ご指摘頂いたとおり、引数が不適な場合は呼び出し元で対処していたのですが、これも「例外」となりうるのですね。失念していました。
引数を呼び出し元でチェックせずそのままcalcに渡し、「別途エラークラスを作らずに、Ruby標準の例外を投げる」というように定めれば、ZeroDivisionErrorやArgumentErrorを投げることで例外の扱いは統一できたと言えるでしょうか？
「ZeroDivisionErrorやArgumentErrorを投げる」でもいいですが、とりわけArgumentErrorについては、コードのバグなのか、入力値のエラーなのかが判別できなくなる可能性があるのが問題になりそうです。
入力値のエラーについては、適切に入力し直すことを促すメッセージを出したいのですが、バグであれば開発者に報告することを促したい、ということになるかもしれません。そのためには、入力値のエラーについては、
class InputError < StandardError; end
みたいなエラークラスを導入して、rescue InputError, ZeroDivisionErrorで入力値のエラー処理を行う、みたいなことが必要になります。
とはいえ、細かいエラーメッセージを出し分けることも面倒ではあるので、rescue StandardErrorでまるっとエラーにする、ということであれば、「ZeroDivisionErrorやArgumentErrorを投げることで例外の扱いは統一できた」ということも言えます。
このへんは目的とこだわり次第ではあるかと思います。
追加でご回答いただきありがとうございます。詳細度と実装量のトレードオフといった感じですね…。バグなのか実行中のエラーなのかわからなくなってしまうのは致命的という感触を受けるので、独自クラスを作ってやったほうがよさそうと感じました。
0
C++において、例外を用いる場合の問題点として**「遅い」ということが挙げられると思います。
(他にもメモリ管理が煩雑になるなどありますが)
Rubyの場合はもともと「速くない」言語**なので例外のデメリットが然程問題にならないように個人的には思います。
なので、Rubyでは例外を避ける理由は希薄です。
逆にnilを返す場合の問題点としては
- 返り値のチェックを行わないと結局例外が発生する箇所が変わるだけになる。
最悪、どこでエラーになったのか分からなくなりデバッグ時に苦労する。
- なぜ
nilが返ってきたのかが、外から判別できない。
例外投げた方が無難に思います。
rb
1if b == 0 then return nil end
は後置if(if修飾子)を用いて
rb
1return nil if b == 0
と書くことができます。
投稿2018/08/29 15:15
総合スコア15149
asmさん、回答ありがとうございます。
Rubyでは例外を避ける必要性は薄いのですね。確かにreturn nilだと例外に比べて外から得られる情報量が少なすぎますね…
後置ifはこのような場合に使えるんですね…！目から鱗でした、ありがとうございます！
0
エラー種類を分類します。
A. a, op. b の妥当性チェック
B. 計算処理のチェック
A については、事前にチェックします。 a, b は数字であること、 op は +, - , * / であることなどです。
B については、例外で処理します。 0 では割り算だけでなく、 オーバーフロー、アンダーフローなどが発生する可能性があります。
投稿2018/08/29 21:52
総合スコア22328
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2018/08/29 23:54
2018/08/30 17:55
2018/08/31 13:34