なるほど、参考になった。
java-ja
May 07, 2012 ~ May 14, 2012
200 messages
なぎせ ゆうき: 初回に鍵ペアをサーバで作って、片方をクライアントに送って、その鍵を持ってる限りはそのユーザと判断するみたいな手法ってアリなのかなあ…?
<pre>なぎせ ゆうき: 初回に鍵ペアをサーバで作って、片方をクライアントに送って、その鍵を持ってる限りはそのユーザと判断するみたいな手法ってアリなのかなあ…?</pre>
なぎせ ゆうき: 連絡という意味だけで言えばメールというプロトコルじゃなくてもいいんだろうけど。
<pre>なぎせ ゆうき: 連絡という意味だけで言えばメールというプロトコルじゃなくてもいいんだろうけど。</pre>
なぎせ ゆうき: ソフトウェアによっては鍵を盗まれたらどうすんだ、みたいな話になりそう
<pre>なぎせ ゆうき: ソフトウェアによっては鍵を盗まれたらどうすんだ、みたいな話になりそう</pre>
まぁ、セキュリティと利便性はトレードオフやからねー。便利さだけを追求すれば「パスなんかめんどくさいもん入れさせない方が便利」とかいう結論になったりならなかったり。
<pre>まぁ、セキュリティと利便性はトレードオフやからねー。便利さだけを追求すれば「パスなんかめんどくさいもん入れさせない方が便利」とかいう結論になったりならなかったり。</pre>
happy_ryo: パスを入れるのを面倒がられる程度にしか、利便性をアピールor提供出来ていないという苦しみを良く味わう
<pre>happy_ryo: パスを入れるのを面倒がられる程度にしか、利便性をアピールor提供出来ていないという苦しみを良く味わう</pre>
なぎせ ゆうき: ユーザ名&パスワードというのもそんなにセキュアじゃないけど、メールアドレス登録させることでリカバリできるようにしてるって感じかしら
<pre>なぎせ ゆうき: ユーザ名&パスワードというのもそんなにセキュアじゃないけど、メールアドレス登録させることでリカバリできるようにしてるって感じかしら</pre>
なぎせ ゆうき: そういえばGmailってリカバリ用に他の連絡先登録することを推奨してなかったか
<pre>なぎせ ゆうき: そういえばGmailってリカバリ用に他の連絡先登録することを推奨してなかったか</pre>
なぎせ ゆうき: うーん。どこから触るのか分からないな…。以前Gmailで電話番号を登録してくれ的なの出たことがあった気がするんだが
<pre>なぎせ ゆうき: うーん。どこから触るのか分からないな…。以前Gmailで電話番号を登録してくれ的なの出たことがあった気がするんだが</pre>
なぎせ ゆうき: Mailシステムとかメールで連絡してくれって訳にはいかないからIDとパスワードだけでやるしかないよな
<pre>なぎせ ゆうき: Mailシステムとかメールで連絡してくれって訳にはいかないからIDとパスワードだけでやるしかないよな</pre>
あー、なんか、普段使っていないGmailアカウントにアクセスするとたまに、昔登録したアドレスを提示されて「このアドレスはGmail以外の連絡先として正しいですか」って確認されることがあった気がする。
<pre>あー、なんか、普段使っていないGmailアカウントにアクセスするとたまに、昔登録したアドレスを提示されて「このアドレスはGmail以外の連絡先として正しいですか」って確認されることがあった気がする。</pre>
nishio_hirokazu: JavaFAQ http://javafaq.jp/S018.html のA-02の解答に不満なんだけどどう思う?
<pre>nishio_hirokazu: JavaFAQ http://javafaq.jp/S018.html のA-02の解答に不満なんだけどどう思う?</pre>
nishio_hirokazu: 例えば、 2 次元空間で 2 本の直線の交点(オブジェクト)を返すメソッドを
<pre>nishio_hirokazu: 例えば、 2 次元空間で 2 本の直線の交点(オブジェクト)を返すメソッドを</pre>
nishio_hirokazu: 考えてみると、交点が存在しない場合は何を返すべきでしょうか。
<pre>nishio_hirokazu: 考えてみると、交点が存在しない場合は何を返すべきでしょうか。</pre>
nishio_hirokazu: このとき上のように考えれば、オブジェクトが存在しないことを表す null を返すのが
<pre>nishio_hirokazu: このとき上のように考えれば、オブジェクトが存在しないことを表す null を返すのが</pre>
nishio_hirokazu: そのメソッドを呼び出す人が「失敗するかもしれない操作だ」と意識する必要があるなら例外を投げるべきだよね
<pre>nishio_hirokazu: そのメソッドを呼び出す人が「失敗するかもしれない操作だ」と意識する必要があるなら例外を投げるべきだよね</pre>
nishio_hirokazu: で、実行時に例外で死ぬのではなくJavaの静的チェックを有効活用したいのであれば、throwsでの宣言が必須になるような種類の例外を投げるべきで、
<pre>nishio_hirokazu: で、実行時に例外で死ぬのではなくJavaの静的チェックを有効活用したいのであれば、throwsでの宣言が必須になるような種類の例外を投げるべきで、</pre>
そのメソッドのJavaDocの@returnに「〜な時{@code null}を返す」みたいなのがあれば、nullを返すという仕様にはあんまり問題は感じないけどなぁ
<pre>そのメソッドのJavaDocの@returnに「〜な時{@code null}を返す」みたいなのがあれば、nullを返すという仕様にはあんまり問題は感じないけどなぁ</pre>
nishio_hirokazu: そうするとそのメソッドを呼び出した人はtry/catchして適切に処理するかthrows宣言するかしなければコンパイルが通らないわけだから、適切に処理することを強制できる
<pre>nishio_hirokazu: そうするとそのメソッドを呼び出した人はtry/catchして適切に処理するかthrows宣言するかしなければコンパイルが通らないわけだから、適切に処理することを強制できる</pre>
takano16: あと、例外的な状態ではなくても、普通にネストしたところから出るためにやっちまう場合もみられるし、バッドノウハウくさいけど。例外だけには限らない気がする。
<pre>takano16: あと、例外的な状態ではなくても、普通にネストしたところから出るためにやっちまう場合もみられるし、バッドノウハウくさいけど。例外だけには限らない気がする。</pre>
cactusman: そのオブジェクトをいろんなところで使う場合に、いちいちnullとかチェックするのが面倒くさいです
<pre>cactusman: そのオブジェクトをいろんなところで使う場合に、いちいちnullとかチェックするのが面倒くさいです</pre>
なぎせ ゆうき: 状況によってはNullObjectパターンでいい場合もあるけど、この例だと微妙だな
<pre>なぎせ ゆうき: 状況によってはNullObjectパターンでいい場合もあるけど、この例だと微妙だな</pre>
nishio_hirokazu: 回答者が「例外的な状況かよく起こる状況か」で例外を使うかどうか決めているように見える…
<pre>nishio_hirokazu: 回答者が「例外的な状況かよく起こる状況か」で例外を使うかどうか決めているように見える…</pre>
nullチェックも例外のハンドルも、利用者側が何か特定の状況を意識して処理を行う、という意味では利用者側の手間の違いはあまり感じないけど…。
<pre>nullチェックも例外のハンドルも、利用者側が何か特定の状況を意識して処理を行う、という意味では利用者側の手間の違いはあまり感じないけど…。</pre>
nishio_hirokazu: 利用者の手間は同じでも、利用者がうっかりした時の被害が違う
<pre>nishio_hirokazu: 利用者の手間は同じでも、利用者がうっかりした時の被害が違う</pre>
nishio_hirokazu: nullであればうっかりしたら、後でその値を実際に使ったタイミングでヌルポ
<pre>nishio_hirokazu: nullであればうっかりしたら、後でその値を実際に使ったタイミングでヌルポ</pre>
null返しのケースだったとして、なんとなくNPEの罠に掛からず、そのまま何となく通ってしまった、というケースが怖いな。
<pre>null返しのケースだったとして、なんとなくNPEの罠に掛からず、そのまま何となく通ってしまった、というケースが怖いな。</pre>
takano16: ドメインによっては何も表現しない、直行していないという点が存在するという概念を導入するというのもありかなーって思ったけど、 null 返すってあんまなくねーって気がする。
<pre>takano16: ドメインによっては何も表現しない、直行していないという点が存在するという概念を導入するというのもありかなーって思ったけど、 null 返すってあんまなくねーって気がする。</pre>
そういう状況の存在を見落として実行時に偶然気づくか、チェック例外のおかげで実装時に必ず気づくか、の違いか。なるほど
<pre>そういう状況の存在を見落として実行時に偶然気づくか、チェック例外のおかげで実装時に必ず気づくか、の違いか。なるほど</pre>
cactusman: 生成場所とぜんぜん違うところで落ちると、デバッグするの大変ですよね
<pre>cactusman: 生成場所とぜんぜん違うところで落ちると、デバッグするの大変ですよね</pre>
takano16: もう片方の例の整数のほうも規定の値を返すという選択肢は十分に考えられてツメが甘い感じがある。
<pre>takano16: もう片方の例の整数のほうも規定の値を返すという選択肢は十分に考えられてツメが甘い感じがある。</pre>
なぎせ ゆうき: 不正なデータが流れてきてある場所で落ちる、という場合に、その不正なデータがどこで生まれたのかを突き止めるのは一般に大変
<pre>なぎせ ゆうき: 不正なデータが流れてきてある場所で落ちる、という場合に、その不正なデータがどこで生まれたのかを突き止めるのは一般に大変</pre>
APIの提供者は、見落とされがちな状況で、実行時にハマるかもしれない状態が存在するなら、実装時にその状況に気づけるように、積極的にチェック例外を投げたほうが良い、という結論になるのかな。
<pre>APIの提供者は、見落とされがちな状況で、実行時にハマるかもしれない状態が存在するなら、実装時にその状況に気づけるように、積極的にチェック例外を投げたほうが良い、という結論になるのかな。</pre>
takano16: 次のところもなんか厳密には不満どころありまくるなぁ。Exception別にプログラミング時に発生するかどうかわからない。発生するのは実行時で、発生の可能性を示唆できるだけのような気がする。
<pre>takano16: 次のところもなんか厳密には不満どころありまくるなぁ。Exception別にプログラミング時に発生するかどうかわからない。発生するのは実行時で、発生の可能性を示唆できるだけのような気がする。</pre>
まぁ(本当かどうかは分からんけど)2002年までの更新みたいだし。時代的にそこまで考えは至ってないんじゃないかな、とも思った。
<pre>まぁ(本当かどうかは分からんけど)2002年までの更新みたいだし。時代的にそこまで考えは至ってないんじゃないかな、とも思った。</pre>
nishio_hirokazu: でも10年前と比べて例外処理周りで進んだところってなんだろう
<pre>nishio_hirokazu: でも10年前と比べて例外処理周りで進んだところってなんだろう</pre>
nishio_hirokazu: http://d.hatena.ne.jp/j5ik2o/20100115/1263570330
<pre>nishio_hirokazu: http://d.hatena.ne.jp/j5ik2o/20100115/1263570330</pre>
nishio_hirokazu: 検査例外は間の「パイプ役」にまでコードの修正を要求するからうざい、って意見はわからなくはない
<pre>nishio_hirokazu: 検査例外は間の「パイプ役」にまでコードの修正を要求するからうざい、って意見はわからなくはない</pre>
nishio_hirokazu: 理屈の上ではパイプの一番端がcatchして非検査例外で包んで投げ直すべきなんだろうけど
<pre>nishio_hirokazu: 理屈の上ではパイプの一番端がcatchして非検査例外で包んで投げ直すべきなんだろうけど</pre>
nishio_hirokazu: 「コードは変更したくない」ってニーズがそんなに強いんだったら仕方ないのかなぁ
<pre>nishio_hirokazu: 「コードは変更したくない」ってニーズがそんなに強いんだったら仕方ないのかなぁ</pre>
nishio_hirokazu: 「使っているライブラリが新しい例外を投げるようになったがコードは変更したくない」ってのがそもそもあんまり健全な状況ではない気がするが。
<pre>nishio_hirokazu: 「使っているライブラリが新しい例外を投げるようになったがコードは変更したくない」ってのがそもそもあんまり健全な状況ではない気がするが。</pre>
なぎせ ゆうき: コード修正しなくても一応は動くけどその例外がでる状況を無視しているだけだよねって状態が健全とは言えないよね
<pre>なぎせ ゆうき: コード修正しなくても一応は動くけどその例外がでる状況を無視しているだけだよねって状態が健全とは言えないよね</pre>
なぎせ ゆうき: メソッドを呼び出すときの「契約」が偏向になっている事実と、コンパイルが通らなくなるということの間にはギャップがあって
<pre>なぎせ ゆうき: メソッドを呼び出すときの「契約」が偏向になっている事実と、コンパイルが通らなくなるということの間にはギャップがあって</pre>
なぎせ ゆうき: 引数で渡すオブジェクトに変数を追加しました、みたいなケースでは契約が変更されている(そのフィールドに適切な値を設定するの必要がある)が、コンパイルは難なく通るというわけで。
<pre>なぎせ ゆうき: 引数で渡すオブジェクトに変数を追加しました、みたいなケースでは契約が変更されている(そのフィールドに適切な値を設定するの必要がある)が、コンパイルは難なく通るというわけで。</pre>
nishio_hirokazu: コンパイラによる検査は魔法の杖ではないから、カバーして欲しいところを全部カバーしてくれるわけでも
<pre>nishio_hirokazu: コンパイラによる検査は魔法の杖ではないから、カバーして欲しいところを全部カバーしてくれるわけでも</pre>
nishio_hirokazu: 余計なことをしてほしくないところをスルーしてくれるわけでもない
<pre>nishio_hirokazu: 余計なことをしてほしくないところをスルーしてくれるわけでもない</pre>
nishio_hirokazu: だから「余計なことをしてほしくないから弱い検査を使う」という判断も「きっちりカバーして欲しいから強い検査を使う」もプログラマが責任をもって選択するべきことで
<pre>nishio_hirokazu: だから「余計なことをしてほしくないから弱い検査を使う」という判断も「きっちりカバーして欲しいから強い検査を使う」もプログラマが責任をもって選択するべきことで</pre>
Junichi KATOH: Maybeモナドは失敗時コンテキストを保存できないから、失敗のコンテキストを扱えるEitherモナドを使うといいのかな。ちょっと勉強してみよう。
<pre>Junichi KATOH: Maybeモナドは失敗時コンテキストを保存できないから、失敗のコンテキストを扱えるEitherモナドを使うといいのかな。ちょっと勉強してみよう。</pre>
全部実行してエラーをまとめて補足したいならscalazのValidationがいいです
<pre>全部実行してエラーをまとめて補足したいならscalazのValidationがいいです</pre>
nishio_hirokazu: そもそもどういう問題を解決したくて出てきたかって考えてみるとさ
<pre>nishio_hirokazu: そもそもどういう問題を解決したくて出てきたかって考えてみるとさ</pre>
nishio_hirokazu: 「失敗しうる関数」を読んだ時に、その関数が失敗したことをどうやって呼び出し元に伝えるか、って時に、
<pre>nishio_hirokazu: 「失敗しうる関数」を読んだ時に、その関数が失敗したことをどうやって呼び出し元に伝えるか、って時に、</pre>
nishio_hirokazu: エラー値を返すって方法では「呼び出し元がチェックしないかもしれない」と「エラー処理をまとめることができない」の2つの問題があった
<pre>nishio_hirokazu: エラー値を返すって方法では「呼び出し元がチェックしないかもしれない」と「エラー処理をまとめることができない」の2つの問題があった</pre>
nishio_hirokazu: そこで原始的な例外処理ではon error gotoなどの方法で、エラーが起きた時にジャンプする先を登録するようになった
<pre>nishio_hirokazu: そこで原始的な例外処理ではon error gotoなどの方法で、エラーが起きた時にジャンプする先を登録するようになった</pre>
nishio_hirokazu: その「例外を投げる可能性がある」という事自体をメソッドの属性にしたということで
<pre>nishio_hirokazu: その「例外を投げる可能性がある」という事自体をメソッドの属性にしたということで</pre>
nishio_hirokazu: 「失敗する可能性がある」という情報を関数の返り値の型にすることで
<pre>nishio_hirokazu: 「失敗する可能性がある」という情報を関数の返り値の型にすることで</pre>
nishio_hirokazu: 呼び出し元が「失敗したかどうか」をチェックすることを型チェックによって強制する
<pre>nishio_hirokazu: 呼び出し元が「失敗したかどうか」をチェックすることを型チェックによって強制する</pre>
nishio_hirokazu: あー。失敗したかチェックをすることなくその値を利用することを禁止する
<pre>nishio_hirokazu: あー。失敗したかチェックをすることなくその値を利用することを禁止する</pre>
nishio_hirokazu: maybeValueがNothingだとどうなるんですか?
<pre>nishio_hirokazu: maybeValueがNothingだとどうなるんですか?</pre>
nishio_hirokazu: Haskellがそんなことをするなんてって言いそうになったけどScalaの話?
<pre>nishio_hirokazu: Haskellがそんなことをするなんてって言いそうになったけどScalaの話?</pre>
nishio_hirokazu: つまりHaskellでもScalaでもMaybe XからJust Xへのある種キャストのような操作を使って失敗を握りつぶすことができてしまう、と。
<pre>nishio_hirokazu: つまりHaskellでもScalaでもMaybe XからJust Xへのある種キャストのような操作を使って失敗を握りつぶすことができてしまう、と。</pre>
nishio_hirokazu: なんでそういう自分の存在意義を否定するようなことをやっちゃうんだろう…
<pre>nishio_hirokazu: なんでそういう自分の存在意義を否定するようなことをやっちゃうんだろう…</pre>
(a, b) だろうが (Just x) だろうが Nothing だろうが、パターンマッチ可能な型ならおけ
<pre>(a, b) だろうが (Just x) だろうが Nothing だろうが、パターンマッチ可能な型ならおけ</pre>
nishio_hirokazu: 網羅されていないパターンマッチという扱いになるわけですか??
<pre>nishio_hirokazu: 網羅されていないパターンマッチという扱いになるわけですか??</pre>
nishio_hirokazu: つまりある関数がなんかの関数を呼び出してMaybe X型の返り値maybeValueを得た時に
<pre>nishio_hirokazu: つまりある関数がなんかの関数を呼び出してMaybe X型の返り値maybeValueを得た時に</pre>
nishio_hirokazu: その値をそのまま返すのがJavaでいう処のなにもtry/catchしないのに相当して
<pre>nishio_hirokazu: その値をそのまま返すのがJavaでいう処のなにもtry/catchしないのに相当して</pre>
nishio_hirokazu: Just xとNothinでパターンマッチしてそれぞれで処理するのがtry/catchしてそれぞれで処理するのに相当して
<pre>nishio_hirokazu: Just xとNothinでパターンマッチしてそれぞれで処理するのがtry/catchしてそれぞれで処理するのに相当して</pre>
nishio_hirokazu: Just xだけなのはtry/catchしてcatch節の中でthrow RuntimeErrorするみたいなものなのかな。
<pre>nishio_hirokazu: Just xだけなのはtry/catchしてcatch節の中でthrow RuntimeErrorするみたいなものなのかな。</pre>
それに近いかもですね。ただ、let (Just x) はあくまでできる、という話で、実際問題こういう使い方してる人は稀だとは思います。
<pre>それに近いかもですね。ただ、let (Just x) はあくまでできる、という話で、実際問題こういう使い方してる人は稀だとは思います。</pre>
nishio_hirokazu: catchしてthrow RuntimeErrorもあんまりやる人いなさそうw
<pre>nishio_hirokazu: catchしてthrow RuntimeErrorもあんまりやる人いなさそうw</pre>
let (x, y) = ... みたいな、網羅性が保証されるパターンマッチは無意識に使ってるでしょうけど
<pre>let (x, y) = ... みたいな、網羅性が保証されるパターンマッチは無意識に使ってるでしょうけど</pre>
nishio_hirokazu: 「その値をそのまま返すのがJavaでいう処のなにもtry/catchしないのに相当」の時「ちゃんとthrowsを書かないといけない」ってのが「返り値がMaybe X」ってのと対応していて
<pre>nishio_hirokazu: 「その値をそのまま返すのがJavaでいう処のなにもtry/catchしないのに相当」の時「ちゃんとthrowsを書かないといけない」ってのが「返り値がMaybe X」ってのと対応していて</pre>
使い捨てプログラムでたまにやりますw > catchして throw RuntimeException
<pre>使い捨てプログラムでたまにやりますw > catchして throw RuntimeException</pre>
nishio_hirokazu: 「Just xとNothinでパターンマッチしてそれぞれで処理するのがtry/catchしてそれぞれで処理するのに相当」の時「throwsを書かなくてよい」と「返り値がMaybe Xでなくてよい」に対応していて
<pre>nishio_hirokazu: 「Just xとNothinでパターンマッチしてそれぞれで処理するのがtry/catchしてそれぞれで処理するのに相当」の時「throwsを書かなくてよい」と「返り値がMaybe Xでなくてよい」に対応していて</pre>
nishio_hirokazu: 「Just xだけなのはtry/catchしてcatch節の中でthrow RuntimeErrorするみたいなもの」の時「検査例外を投げるっていう静的にチェックできる情報がチェックできない非検査例外に変換された」のが「Maybeが持っていた失敗しうるという静的にチェックできる情報ができない実行時のエラーに変換された」と対応する。
<pre>nishio_hirokazu: 「Just xだけなのはtry/catchしてcatch節の中でthrow RuntimeErrorするみたいなもの」の時「検査例外を投げるっていう静的にチェックできる情報がチェックできない非検査例外に変換された」のが「Maybeが持っていた失敗しうるという静的にチェックできる情報ができない実行時のエラーに変換された」と対応する。</pre>
別の見方として、検査例外と非検査例外は、動的スコープ VS. 静的スコープと見ることもできます
<pre>別の見方として、検査例外と非検査例外は、動的スコープ VS. 静的スコープと見ることもできます</pre>
(非検査) 例外をthrowしたときに、どこでcatchされるかは、コールグラフに基づいて動的に決定される。で、呼び出し元は呼び出し先がどういう例外を出してくるかは、簡単にはわからない
<pre>(非検査) 例外をthrowしたときに、どこでcatchされるかは、コールグラフに基づいて動的に決定される。で、呼び出し元は呼び出し先がどういう例外を出してくるかは、簡単にはわからない</pre>
検査例外では、catch/throwsを全て上位のメソッドに書き連ねていくことで、呼び出し側(コンパイラも)が、投げ得る検査例外の種類を全て知ることができる
<pre>検査例外では、catch/throwsを全て上位のメソッドに書き連ねていくことで、呼び出し側(コンパイラも)が、投げ得る検査例外の種類を全て知ることができる</pre>
非検査例外という動的で扱いにくいものを、検査例外という静的な形に無理矢理したということなのかなあと
<pre>非検査例外という動的で扱いにくいものを、検査例外という静的な形に無理矢理したということなのかなあと</pre>
ただ、例外とはなんぞやという問題が別にあって、何を検査例外とするかについて統一見解が無いので、しっちゃかめっちゃかになって、検査例外のありがたみが薄れてるのでは、とかふと考えました。
<pre>ただ、例外とはなんぞやという問題が別にあって、何を検査例外とするかについて統一見解が無いので、しっちゃかめっちゃかになって、検査例外のありがたみが薄れてるのでは、とかふと考えました。</pre>
あと、現状のJava検査例外の型システムだと、例外を透過的に投げるようなメソッド、たとえば using(...) { .... } みたいなのを書きたいときに凄く困るという話があって
<pre>あと、現状のJava検査例外の型システムだと、例外を透過的に投げるようなメソッド、たとえば using(...) { .... } みたいなのを書きたいときに凄く困るという話があって</pre>
あ、usingは、 def using[A](resource: A)(fn: A=> Unit): Unit = try { fn(resource) } finally { resource.close() }
<pre>あ、usingは、 def using[A](resource: A)(fn: A=> Unit): Unit = try { fn(resource) } finally { resource.close() }</pre>
このとき、fn(resource)実行中に起きた例外はそのままusingの呼び出し元に「丸投げ」して欲しいわけですが、今の検査例外の型システムだとそういう関数のシグニチャをそもそも書けない…
<pre>このとき、fn(resource)実行中に起きた例外はそのままusingの呼び出し元に「丸投げ」して欲しいわけですが、今の検査例外の型システムだとそういう関数のシグニチャをそもそも書けない…</pre>
個人的には、検査例外というアイデアは良いけど、その実装(型システム含めて)がまだ十分でなくて、
<pre>個人的には、検査例外というアイデアは良いけど、その実装(型システム含めて)がまだ十分でなくて、</pre>
nishio_hirokazu: そうなんですよね「どういう失敗をしうるか」をメタデータに入れるのは良いアイデア、という点と
<pre>nishio_hirokazu: そうなんですよね「どういう失敗をしうるか」をメタデータに入れるのは良いアイデア、という点と</pre>
nishio_hirokazu: それの現状の実装がいまいち、という点は全く同意です。
<pre>nishio_hirokazu: それの現状の実装がいまいち、という点は全く同意です。</pre>
nishio_hirokazu: throws節で人間に宣言させるべきだったんだろうか
<pre>nishio_hirokazu: throws節で人間に宣言させるべきだったんだろうか</pre>
nishio_hirokazu: それともどこでどういう例外が起こりえてどこまで伝搬しうるかは機械的に判断できることだから
<pre>nishio_hirokazu: それともどこでどういう例外が起こりえてどこまで伝搬しうるかは機械的に判断できることだから</pre>
nishio_hirokazu: たとえばIDEなんかが「この関数呼び出しは例外Xを投げる可能性がありますがこの例外はどこでもキャッチされていません」みたいな警告を出せばいいんだろうか。
<pre>nishio_hirokazu: たとえばIDEなんかが「この関数呼び出しは例外Xを投げる可能性がありますがこの例外はどこでもキャッチされていません」みたいな警告を出せばいいんだろうか。</pre>
nishio_hirokazu: http://www.lcs.mit.edu/publications/pubs/pdf/MIT-LCS-TR-561.pdf
<pre>nishio_hirokazu: http://www.lcs.mit.edu/publications/pubs/pdf/MIT-LCS-TR-561.pdf</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>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>
nishio_hirokazu: 「多くの例外処理メカニズムでは例外が自動的に呼び出し元に伝搬していくけど、これは好ましくない。
<pre>nishio_hirokazu: 「多くの例外処理メカニズムでは例外が自動的に呼び出し元に伝搬していくけど、これは好ましくない。</pre>
nishio_hirokazu: 仕様に書いていない例外を投げる可能性が出てくるからだ」
<pre>nishio_hirokazu: 仕様に書いていない例外を投げる可能性が出てくるからだ」</pre>
nishio_hirokazu: Therefore, we decided to turn all unhandled exceptions into a special exception called "failure" and propagate it. This mechanism seems to work well in practice.
<pre>nishio_hirokazu: Therefore, we decided to turn all unhandled exceptions into a special exception called "failure" and propagate it. This mechanism seems to work well in practice.</pre>
なぎせ ゆうき: CLUってのはプログラム言語なのか http://ja.wikipedia.org/wiki/CLU
<pre>なぎせ ゆうき: CLUってのはプログラム言語なのか http://ja.wikipedia.org/wiki/CLU</pre>




