<pre>なぎせ ゆうき: AndroidとかiOSとかみたいなデバイスの想定だけど。</pre>

<pre>なぎせ ゆうき: 鍵無くしたらどうしようもないのは同じだな</pre>

<pre>なぎせ ゆうき: 連絡という意味だけで言えばメールというプロトコルじゃなくてもいいんだろうけど。</pre>

<pre>なぎせ ゆうき: ソフトウェアによっては鍵を盗まれたらどうすんだ、みたいな話になりそう</pre>

<pre>なぎせ ゆうき: ユーザ名&amp;パスワードというのもそんなにセキュアじゃないけど、メールアドレス登録させることでリカバリできるようにしてるって感じかしら</pre>

<pre>なぎせ ゆうき: そういえばGmailってリカバリ用に他の連絡先登録することを推奨してなかったか</pre>

<pre>なぎせ ゆうき: うーん。どこから触るのか分からないな…。以前Gmailで電話番号を登録してくれ的なの出たことがあった気がするんだが</pre>

<pre>なぎせ ゆうき: Mailシステムとかメールで連絡してくれって訳にはいかないからIDとパスワードだけでやるしかないよな</pre>

<pre>なぎせ ゆうき: そのへんのポリシーは参考になるのかもしれない</pre>

<pre>takano16: 不満ですね。</pre>

<pre>nishio_hirokazu: &gt;&gt;</pre>

<pre>nishio_hirokazu: 例えば、 2 次元空間で 2 本の直線の交点（オブジェクト）を返すメソッドを</pre>

<pre>nishio_hirokazu: 考えてみると、交点が存在しない場合は何を返すべきでしょうか。</pre>

<pre>nishio_hirokazu: このとき上のように考えれば、オブジェクトが存在しないことを表す null を返すのが</pre>

<pre>nishio_hirokazu: 妥当であるということになります。</pre>

<pre>nishio_hirokazu: &lt;&lt;</pre>

<pre>nishio_hirokazu: これ絶対将来的に誰かがヌルポ　ガッ ってなるだろ</pre>

<pre>cactusman: ｶﾞｯ</pre>

<pre>takano16: NoSuchPointExceptionみたいなのつくればいい。</pre>

<pre>takano16: NotFoundPointのうが自然か</pre>

<pre>nishio_hirokazu: そのメソッドを呼び出す人が「失敗するかもしれない操作だ」と意識する必要があるなら例外を投げるべきだよね</pre>

<pre>cactusman: . 　　Λ＿Λ　　 ＼＼</pre>

<pre>cactusman: 　 （　・∀・）　　　|　|　ｶﾞｯ</pre>

<pre>cactusman: 　と　　　　）　 　 |　|</pre>

<pre>cactusman: 　　 Ｙ　/ノ　　　 人</pre>

<pre>cactusman: 　　　 /　）　 　 &lt; 　&gt;_Λ∩</pre>

<pre>cactusman: 　 ＿/し&#39;　／／. Ｖ｀Д´）/</pre>

<pre>cactusman: 　 （＿フ彡　　　　　 　/</pre>

<pre>nishio_hirokazu: うんうん</pre>

<pre>cactusman: まぁ、nullチェックめんどいから例外でもいいんじゃない</pre>

<pre>cactusman: -1返すのもおんなじで</pre>

<pre>cactusman: チェックめんどい</pre>

<pre>nishio_hirokazu: で、実行時に例外で死ぬのではなくJavaの静的チェックを有効活用したいのであれば、throwsでの宣言が必須になるような種類の例外を投げるべきで、</pre>

<pre>takano16: あと、例外的な状態ではなくても、普通にネストしたところから出るためにやっちまう場合もみられるし、バッドノウハウくさいけど。例外だけには限らない気がする。</pre>

<pre>cactusman: そのオブジェクトをいろんなところで使う場合に、いちいちnullとかチェックするのが面倒くさいです</pre>

<pre>takano16: 回答者は null チェックが好きなのでは。</pre>

<pre>なぎせ ゆうき: 状況によってはNullObjectパターンでいい場合もあるけど、この例だと微妙だな</pre>

<pre>nishio_hirokazu: 例外であればうっかりしたらコンパイル時エラーになる</pre>

<pre>nishio_hirokazu: nullであればうっかりしたら、後でその値を実際に使ったタイミングでヌルポ</pre>

<pre>nishio_hirokazu: デバッグのコストが桁違い</pre>

<pre>cactusman: それだったら、例外で気付ける方がいいかな</pre>

<pre>takano16: もう片方の例の整数のほうも規定の値を返すという選択肢は十分に考えられてツメが甘い感じがある。</pre>

<pre>なぎせ ゆうき: 不正なデータが流れてきてある場所で落ちる、という場合に、その不正なデータがどこで生まれたのかを突き止めるのは一般に大変</pre>

<pre>takano16: 型推論レベルの安全性が書かれてるようにみえる・・・</pre>

<pre>takano16: 次というか [S018 Q-04] だった。</pre>

<pre>nishio_hirokazu: でも10年前と比べて例外処理周りで進んだところってなんだろう</pre>

<pre>nishio_hirokazu: 10年前もfinallyってあったよね</pre>

<pre>nishio_hirokazu: http://d.hatena.ne.jp/j5ik2o/20100115/1263570330</pre>

<pre>nishio_hirokazu: あー、なるほど</pre>

<pre>cactusman: Java5からの人間だから、その辺わかんない</pre>

<pre>nishio_hirokazu: 検査例外は間の「パイプ役」にまでコードの修正を要求するからうざい、って意見はわからなくはない</pre>

<pre>cactusman: 検査例外を上まで投げるからそういうことになる</pre>

<pre>nishio_hirokazu: 理屈の上ではパイプの一番端がcatchして非検査例外で包んで投げ直すべきなんだろうけど</pre>

<pre>nishio_hirokazu: 「コードは変更したくない」ってニーズがそんなに強いんだったら仕方ないのかなぁ</pre>

<pre>nishio_hirokazu: 「使っているライブラリが新しい例外を投げるようになったがコードは変更したくない」ってのがそもそもあんまり健全な状況ではない気がするが。</pre>

<pre>cactusman: 投げられた例外はどっかで処理しないといけないしね。</pre>

<pre>なぎせ ゆうき: コード修正しなくても一応は動くけどその例外がでる状況を無視しているだけだよねって状態が健全とは言えないよね</pre>

<pre>なぎせ ゆうき: メソッドを呼び出すときの「契約」が偏向になっている事実と、コンパイルが通らなくなるということの間にはギャップがあって</pre>

<pre>なぎせ ゆうき: 引数で渡すオブジェクトに変数を追加しました、みたいなケースでは契約が変更されている(そのフィールドに適切な値を設定するの必要がある)が、コンパイルは難なく通るというわけで。</pre>

<pre>なぎせ ゆうき: 非検査例外もそこは一緒だと思ってる</pre>

<pre>nishio_hirokazu: そうかー</pre>

<pre>nishio_hirokazu: コンパイラによる検査は魔法の杖ではないから、カバーして欲しいところを全部カバーしてくれるわけでも</pre>

<pre>nishio_hirokazu: 余計なことをしてほしくないところをスルーしてくれるわけでもない</pre>

<pre>nishio_hirokazu: だから「余計なことをしてほしくないから弱い検査を使う」という判断も「きっちりカバーして欲しいから強い検査を使う」もプログラマが責任をもって選択するべきことで</pre>

<pre>nishio_hirokazu: 「どっちが正しいか」ってもんじゃない、と。</pre>

<pre>Junichi KATOH: Maybeモナドは失敗時コンテキストを保存できないから、失敗のコンテキストを扱えるEitherモナドを使うといいのかな。ちょっと勉強してみよう。</pre>

<pre>Junichi KATOH: ねこはるのサイトでそれ理解したわ</pre>

<pre>nishio_hirokazu: そもそも手続き型のモデルだよね。</pre>

<pre>nishio_hirokazu: 例外処理ってさ</pre>

<pre>nishio_hirokazu: そもそもどういう問題を解決したくて出てきたかって考えてみるとさ</pre>

<pre>nishio_hirokazu: エラー値を返すって方法では「呼び出し元がチェックしないかもしれない」と「エラー処理をまとめることができない」の2つの問題があった</pre>

<pre>nishio_hirokazu: そこで原始的な例外処理ではon error gotoなどの方法で、エラーが起きた時にジャンプする先を登録するようになった</pre>

<pre>nishio_hirokazu: 先日のJavaの検査例外の話は</pre>

<pre>nishio_hirokazu: その「例外を投げる可能性がある」という事自体をメソッドの属性にしたということで</pre>

<pre>nishio_hirokazu: いっぽうMaybeモナドなどをつかった場合は</pre>

<pre>nishio_hirokazu: 「失敗する可能性がある」という情報を関数の返り値の型にすることで</pre>

<pre>nishio_hirokazu: 呼び出し元が「失敗したかどうか」をチェックすることを型チェックによって強制する</pre>

<pre>nishio_hirokazu: と表現したほうが紛れがない？</pre>

<pre>nishio_hirokazu: 実行時エラー？</pre>

<pre>nishio_hirokazu: それは知らなかったです。</pre>

<pre>nishio_hirokazu: つまりHaskellでもScalaでもMaybe XからJust Xへのある種キャストのような操作を使って失敗を握りつぶすことができてしまう、と。</pre>

<pre>nishio_hirokazu: 台無しですな…</pre>

<pre>nishio_hirokazu: なんでそういう自分の存在意義を否定するようなことをやっちゃうんだろう…</pre>

<pre>nishio_hirokazu: その値をそのまま返すのがJavaでいう処のなにもtry/catchしないのに相当して</pre>

<pre>nishio_hirokazu: Just xとNothinでパターンマッチしてそれぞれで処理するのがtry/catchしてそれぞれで処理するのに相当して</pre>

<pre>nishio_hirokazu: 「Just xだけなのはtry/catchしてcatch節の中でthrow RuntimeErrorするみたいなもの」の時「検査例外を投げるっていう静的にチェックできる情報がチェックできない非検査例外に変換された」のが「Maybeが持っていた失敗しうるという静的にチェックできる情報ができない実行時のエラーに変換された」と対応する。</pre>

<pre>nishio_hirokazu: ということか。</pre>

<pre>nishio_hirokazu: そうなんですよね「どういう失敗をしうるか」をメタデータに入れるのは良いアイデア、という点と</pre>

<pre>nishio_hirokazu: それの現状の実装がいまいち、という点は全く同意です。</pre>

<pre>nishio_hirokazu: throws節で人間に宣言させるべきだったんだろうか</pre>

<pre>nishio_hirokazu: それともどこでどういう例外が起こりえてどこまで伝搬しうるかは機械的に判断できることだから</pre>

<pre>nishio_hirokazu: たとえばIDEなんかが「この関数呼び出しは例外Xを投げる可能性がありますがこの例外はどこでもキャッチされていません」みたいな警告を出せばいいんだろうか。</pre>

<pre>nishio_hirokazu: CLUの例外処理が面白い</pre>

<pre>nishio_hirokazu: http://www.lcs.mit.edu/publications/pubs/pdf/MIT-LCS-TR-561.pdf</pre>

<pre>nishio_hirokazu: We wanted to be able to call a procedure knowing just its specification, not its implementation. However, if exceptions are propagated automatically, a procedure may raise an exception not described in its specification.</pre>

<pre>nishio_hirokazu: 「多くの例外処理メカニズムでは例外が自動的に呼び出し元に伝搬していくけど、これは好ましくない。</pre>

<pre>nishio_hirokazu: 仕様に書いていない例外を投げる可能性が出てくるからだ」</pre>

<pre>nishio_hirokazu: Javaの検査例外の考え方のもっと先鋭化した漢字</pre>

<pre>nishio_hirokazu: Therefore, we decided to turn all unhandled exceptions into a special exception called &quot;failure&quot; and propagate it. This mechanism seems to work well in practice.</pre>

<pre>nishio_hirokazu: なるほど。</pre>

<pre>なぎせ ゆうき: 気になるが…。abstractの内容がイマイチ頭に入ってこない…。</pre>

<pre>nishio_hirokazu: アブスト読んでなかった</pre>

<pre>なぎせ ゆうき: CLUってのはプログラム言語なのか http://ja.wikipedia.org/wiki/CLU</pre>

<pre>nishio_hirokazu: うんうん</pre>

<pre>nishio_hirokazu: 例外処理メカニズムをかなり発展させた言語</pre>

<pre>nishio_hirokazu: なので例外処理のところだけ読んでた</pre>

<pre>なぎせ ゆうき: なるほど。これはCLUの歴史について書かれた文章なのか</pre>

<pre>なぎせ ゆうき: 英文がナナメ読みできるようになりたいお…。</pre>

<pre>なぎせ ゆうき: とにかく量をよむしかないんだろうが。</pre>

<pre>なぎせ ゆうき: 例外ってどこのセクションだろ…。</pre>

<pre>nishio_hirokazu: exceptionで検索</pre>

<pre>なぎせ ゆうき: あった。3.9 Exception Handlingかな</pre>

<pre>nishio_hirokazu: ｙ</pre>

<pre>なぎせ ゆうき: じっくり読んでみる</pre>