アカウント名:
パスワード:
エラーはエラーとして扱わないとものすごいしっぺ返しをくうんだがなあ。ゼロ除算で0を返すなんて、例外が発生してプログラムが止まるよりひどいことになるけども。こんなのが議論になること自体おかしい気がするけど、もしかしたらなにか有益な議論がなされてるのかな。英語を追う気力がないのであちらのストーリーを開くつもりもないけどw
ただ、ゼロ除算のエラーとしてのクリティカルさは実務への影響に対して「異常に高い」とは思う。
これが、金融系とか数字そのものがアウトプットの用途だと困っちゃう話なんだが・・・
例えばページブレーク処理とか画面座標計算とかだと、エラーだろうが0デフォだろうが別にいいっちゃいいんだよね。そこに至ること自体が異常で、別に対処する必要もないんだけど、ゼロ除で止まられるのもうっとおしい。
C++のたぐいのtry-throw-catch例外処理ってのが面倒の原因の気もする。BASICやPL/Iのような、昔懐かしのon errorが使いやすい場合もありそう。ゼロ除算があっても無視して突き進め、みたいなことできるし。
On Error Resume Next 最強伝説
それを見るだけで吐き気が…
以前に別のストーリーでも書いたけど、テレビでタレントが「iPhoneの計算機で、ゼロで割るとエラーって表示される！」と、まるで計算結果を表示しないのが不思議で大発見のように発言しちゃって、出演者たちが感心してるような情景が視聴できる日本を見ると、やはり「エラー。ゼロで除算はできませんよ。算数を勉強し直せ」って表示すべきだと思いました。
でも今どきの小学校では、「教えるべし」とはなってないんですよね...図書館で算数の教科書をいくつか見たけど、自分が小学生の時に見たゼロ除算の記述はなかったし、学習指導要領 [mext.go.jp](現行の資料が見当たらない)にも入ってないっぽいし。
運が良ければゼロ除算について少し詳しく喋ってくれる先生にあたるかも
生レバ食のハナシとかぶって感じられますた。
たぶん同じ番組見てましたが、その時の違和感はそれだったのだとわかりました。ERRORとかNaN等ではなくカタカナで「エラー」なのがそんなに珍しいのかと思ってましたが、出演者達は0で割れない事に驚いていたとは。
なんでこんな話に1000件もコメントつくのかさっぱりわからんな。仮に既定の値を作ったとして、やっぱり除算の結果見てゼロで割ってないか調べなきゃいけないのは変わらんとおもうんだが。先に調べるか、あとで調べるかだけの違いしかなくて、例外が発生しないなら処理系まかせにはできないよね。余計面倒じゃんか。例外が発生するとバグで、そうでなければ正常という判断基準なのか？＃いや、ハンドラ登録すればいいから。
なんでこんな話に1000件もコメントつくのかさっぱりわからんな。
コミュニティ人口の問題かな。Slashdotのコメント数をスラドのコメント数で割れば規模の比率が割り出せそう。既に数十コメント投稿されているからゼロチェックはいらんな。
ていうか、独立したはずなのに未だに一方的に親子関係を保ってますねスラド。
そのしっぺ返しの実例が思い浮かばなかった
3D計算でもエラー処理なんかせず0でスルーする(場合もある)し財務計算でもエラー表示とかはするけどホントに0除算計算なんてさせないしというかUI的に除算エラーです、なんて見せ方しないしな
エラーフラグは立ててくれるとうれしいけどデフォルトで処理継続してもありな気はする
0にする場合もありますが、1.0にする場合や0.5にする場合、1e6fにする場合もありますし…。
現在の仕様を踏まえれば、処理中に０除算が発生した時点で何らかのバグがあるから処理を止める。プログラムを修正して再実行する。という、かなり前の汎用機みたいなユーザの利用形式を想定している為といえるだろう。
大昔の単一演算しかしないプログラムではなく、最近では統合環境型の初めから終わりまで何でもやるタイプのプログラムが増えた。恐らく２つの理由により上記利用形式を取ることが出きないのだと思う。１）一部の処理でエラーが出て他の処理まで停止させることが好ましくない。２）いきなりトン死されてはプログラムが管理している一時データの保全ができない。 時間がかかる処理を全く最初からやり直させるのは好ましくない。
>おそらく２つの理由により上記利用形式を取ることが出きないのだと思う。
だったら普通に0除算をトラップして、その場合の処理を書けばいいのでは?どんな処理が妥当なのかは、設計しているシステムによって内容が変わるので、0除算って条件だけでは決まらない。
面倒くさいから、トラップ処理を書きたくないから、何か一定の値を放り込んで済ませたいってのは、正しくないと思う。
>エラーはエラーとして扱わないとものすごいしっぺ返しをくうんだがなあ。だから、具体的に「ものすごいしっぺ返し」って何よ？ってストーリーでしょ。
2000年問題とか覚えてないんですか？19xxというデフォルト値を想定することによる「ものすごいしっぺ返し」がいろいろと挙げられてたはずですが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
エラーはエラーとして現出させよ (スコア:0)
エラーはエラーとして扱わないとものすごいしっぺ返しをくうんだがなあ。
ゼロ除算で0を返すなんて、例外が発生してプログラムが止まるよりひどいことになるけども。
こんなのが議論になること自体おかしい気がするけど、もしかしたらなにか有益な議論がなされてるのかな。
英語を追う気力がないのであちらのストーリーを開くつもりもないけどw
Re:エラーはエラーとして現出させよ (スコア:1)
ただ、ゼロ除算のエラーとしてのクリティカルさは実務への影響に対して「異常に高い」とは思う。
これが、金融系とか数字そのものがアウトプットの用途だと困っちゃう話なんだが・・・
例えばページブレーク処理とか画面座標計算とかだと、エラーだろうが0デフォだろうが別にいいっちゃいいんだよね。
そこに至ること自体が異常で、別に対処する必要もないんだけど、ゼロ除で止まられるのもうっとおしい。
Re: (スコア:0)
C++のたぐいのtry-throw-catch例外処理ってのが面倒の原因の気もする。
BASICやPL/Iのような、昔懐かしのon errorが使いやすい場合もありそう。
ゼロ除算があっても無視して突き進め、みたいなことできるし。
Re:エラーはエラーとして現出させよ (スコア:2, おもしろおかしい)
On Error Resume Next 最強伝説
Re: (スコア:0)
それを見るだけで吐き気が…
Re:エラーはエラーとして現出させよ (スコア:1)
以前に別のストーリーでも書いたけど、テレビでタレントが「iPhoneの計算機で、ゼロで割るとエラーって表示される！」と、まるで計算結果を表示しないのが不思議で大発見のように発言しちゃって、出演者たちが感心してるような情景が視聴できる日本を見ると、やはり「エラー。ゼロで除算はできませんよ。算数を勉強し直せ」って表示すべきだと思いました。
Re: (スコア:0)
でも今どきの小学校では、「教えるべし」とはなってないんですよね...
図書館で算数の教科書をいくつか見たけど、自分が小学生の時に見たゼロ除算の記述はなかったし、学習指導要領 [mext.go.jp](現行の資料が見当たらない)にも入ってないっぽいし。
運が良ければゼロ除算について少し詳しく喋ってくれる先生にあたるかも
Re: (スコア:0)
生レバ食のハナシとかぶって感じられますた。
Re: (スコア:0)
たぶん同じ番組見てましたが、その時の違和感はそれだったのだとわかりました。
ERRORとかNaN等ではなくカタカナで「エラー」なのがそんなに珍しいのかと思ってましたが、出演者達は0で割れない事に驚いていたとは。
Re: (スコア:0)
なんでこんな話に1000件もコメントつくのかさっぱりわからんな。
仮に既定の値を作ったとして、やっぱり除算の結果見てゼロで割ってないか調べなきゃいけないのは変わらんとおもうんだが。
先に調べるか、あとで調べるかだけの違いしかなくて、例外が発生しないなら処理系まかせにはできないよね。
余計面倒じゃんか。
例外が発生するとバグで、そうでなければ正常という判断基準なのか？
＃いや、ハンドラ登録すればいいから。
Re: (スコア:0)
なんでこんな話に1000件もコメントつくのかさっぱりわからんな。
コミュニティ人口の問題かな。
Slashdotのコメント数をスラドのコメント数で割れば規模の比率が割り出せそう。
既に数十コメント投稿されているからゼロチェックはいらんな。
Re:エラーはエラーとして現出させよ (スコア:1)
ていうか、独立したはずなのに未だに一方的に親子関係を保ってますねスラド。
Re: (スコア:0)
そのしっぺ返しの実例が思い浮かばなかった
3D計算でもエラー処理なんかせず0でスルーする(場合もある)し
財務計算でもエラー表示とかはするけどホントに0除算計算なんてさせないし
というかUI的に除算エラーです、なんて見せ方しないしな
エラーフラグは立ててくれるとうれしいけどデフォルトで処理継続しても
ありな気はする
Re: (スコア:0)
0にする場合もありますが、1.0にする場合や0.5にする場合、1e6fにする場合もありますし…。
Re: (スコア:0)
現在の仕様を踏まえれば、
処理中に０除算が発生した時点で何らかのバグがあるから処理を止める。プログラムを修正して再実行する。
という、かなり前の汎用機みたいなユーザの利用形式を想定している為といえるだろう。
大昔の単一演算しかしないプログラムではなく、最近では統合環境型の初めから終わりまで何でもやるタイプの
プログラムが増えた。恐らく２つの理由により上記利用形式を取ることが出きないのだと思う。
１）一部の処理でエラーが出て他の処理まで停止させることが好ましくない。
２）いきなりトン死されてはプログラムが管理している一時データの保全ができない。
時間がかかる処理を全く最初からやり直させるのは好ましくない。
Re: (スコア:0)
>おそらく２つの理由により上記利用形式を取ることが出きないのだと思う。
だったら普通に0除算をトラップして、その場合の処理を書けばいいのでは?
どんな処理が妥当なのかは、設計しているシステムによって内容が変わるので、
0除算って条件だけでは決まらない。
面倒くさいから、トラップ処理を書きたくないから、
何か一定の値を放り込んで済ませたいってのは、正しくないと思う。
Re: (スコア:0)
>エラーはエラーとして扱わないとものすごいしっぺ返しをくうんだがなあ。
だから、具体的に「ものすごいしっぺ返し」って何よ？ってストーリーでしょ。
Re: (スコア:0)
2000年問題とか覚えてないんですか？
19xxというデフォルト値を想定することによる「ものすごいしっぺ返し」がいろいろと挙げられてたはずですが。