[Java SE 7] 次世代Javaの動向 5 [dolphin]

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 05/09 13:00 / Filesize : 224 KB / Number-of Response : 992
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

1 名前：デフォルトの名無しさん [2007/05/12(土) 08:25:15 ]: 前スレ

[mustang/Java SE 6] 次世代Javaの動向 4 [dolphin]
pc11.2ch.net/test/read.cgi/tech/1163986696/

[mustang] 次世代Javaの動向 3 [dolphin]
pc8.2ch.net/test/read.cgi/tech/1157227790/

次世代Javaの動向　２
pc8.2ch.net/test/read.cgi/tech/1147881822/

【Java】次世代Java・J2SE1.6の動向【Mustang】
pc8.2ch.net/test/read.cgi/tech/1081698555/
411 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 14:30:17 ]: んなもんソースレビューで片付けろよ
412 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 14:44:28 ]: closeが検査例外を投げるバカなAPI
413 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 14:49:51 ]: >>411
第三者の作ったライブラリやフレームワーク使う時は
それらも全部ソースレビューすんの？
414 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 14:51:10 ]: 必ずソースが見れるとは限らんし
415 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 15:05:42 ]: >>405
IOExceptionとかって多くの場合リカバリできるの?
リソースの解放はfinallyでやるからチェック付き例外とは関係ないと思うし

なるべく例外がチェックできるべきだという意見は多い様に見えるが、一般的にそれらの例外がほとんどリカバリできる処理を書けないならば >>400の言うようにAPIの設計の問題では?
416 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 15:10:27 ]: ソケット使って読み書きしてる時にIOExceptionが発生したらリトライするとかあるよね
417 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 15:53:29 ]: >>416
そういう特定の事情のために、すべてのIO処理で面倒なコードを書かないといけないのはアホ
418 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 15:56:09 ]: というか、例外が出ないコードで例外の補足が必要になるのが、設計ミス
System.in.read()
とか
419 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 15:57:17 ]: 面倒っても、throws IOException を宣言するくらいのもの。
その場で対処しない例外は上へ送る。
420 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 16:02:53 ]: System.in.read() ってプラットフォーム側の標準入出力の実装方法によっては
例外が出る可能性があるんだが
421 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 16:10:33 ]: 俺としてはNumberFormatExceptionが実行時例外なのが許せないくらいなんだが。
外側のことは一切信用しないという性悪説プログラミングが心情だとね。
422 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 16:18:48 ]: 俺はUserTransactionのメソッドを使ってみたとき、
Javaのチェック例外は、API側が使い方を根本的に間違ってると痛感したよｗ
423 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 16:24:01 ]: >>412みたいな事を言う奴から間違ってると言われても
424 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 16:31:07 ]: >>419
それで上へ送った例外は結局どうなるわけ?
throws IOExceptionをまき散らして、
RuntimeExceptionになるか握りつぶされるぐらいじゃないの?

>>421
一切信用しないというのはいいが、それはどうやって処理される?
他の値で代用するのは多くの場合問題がある気がするし、
再度入力を促すことになると思うが、
可能な場合と不可能な場合(処理を中断するしかない場合)があると思う

...NumberFormatExceptionに関しては微妙な気がしてきた
RuntimeExceptionでよい場合も多いと思うが...
425 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 16:54:22 ]: 最近じゃ例外もAOPで処理するし、リソースはfinallyで閉じるからあまり関係ないしな
matz氏がブログで、例外をぎりぎりまで捕捉しないのがRuby流って書いてたけど
結局はそれがいちばん効率的で、開発者に都度catch処理を強制するよりも品質が上がるんだよね。
例外処理がなくても、異常終了で落ちるからテスト時にすぐわかるが、
catchで不用意に握りつぶされた例外はやっかいだし
426 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 17:06:07 ]: 何層か下のフレームワーク/ライブラリが投げてくる実装依存の例外もやっかいだけどな。

面倒くさいから検査例外は無い方が良いとか考えてる奴は、
例外関連のドキュメントなんて書かないから品質ズタボロのコードを量産する。
427 名前：424 mailto:sage [2007/09/02(日) 17:27:46 ]: >>425
アプリケーション(基本的なライブラリでない)でのチェック付き例外は有用と見られているはずだ
アプリケーションレベルではリカバするべき例外を決めることができて、チェック付き例外で強制できる

アスペクトを使うことでIO例外をアプリの例外へ変換とかはうまく書けるが、
各メソッドごとの例外処理を常にうまく分離して書けるわけではない

テスト時にすぐわかるというのは理由にならないはずだ
再現が難しい例外だってあるから
それよりも発生したときなにもできないことが多いというのが理由だと思う
428 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 17:28:11 ]: なんか次世代関係なくなってね？
JAVAの例外について勉強するスレとかたててそっちでやれ
429 名前：デフォルトの名無しさん [2007/09/02(日) 18:30:35 ]: 例外処理が煩わしいのであれば、
例外処理を包含したテンプレートパターンを適用して処理すればいい。
APIは面倒か面倒じゃないかではなく、安全か安全ではないかが重要。

APIは極力安全に使えるように「馬鹿向け」に作られているが、
本当の馬鹿にはその意味すらわからないらしいｗ
430 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 18:57:24 ]: わずらわしいどうの以前にその例外をどう扱うべきかというパターン自体が俺みたいな初心者にはわからない
使われる側でチェック例外を投げてから使う側で遺言を言ったあとRuntimeExceptionでラップするとか、
キャンセルなどの特殊な状況を処理するために使うとか、なんだろうか
431 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 21:40:59 ]: 捕捉する場所によって扱い方も異なるとしか言い様がないな。
ライブラリ書いてるなら、抽象的な例外でラップして投げなおすだろうし。
フレームワークならコントローラで一括処理で、それ以外では全部投げっぱなし。
432 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 21:49:00 ]: 個人的にはチェック例外＝病気の診断、ランタイム例外＝安楽死とか思ってる
で、今直せる見込みのない病人がいるとして、いろんな病院をたらいまわしたり（チェック例外のままthrowsしまくる）、
病気ではないとして放置したり（例外を握りつぶす）、
秘密裏に抹殺したり（System.exit(0)）、
するよりはランタイム例外にして安楽死させたほうがいいような気はするんだけどな。

でもそのあたりの常識やパターンやガイドラインみたいなものがないと実際何をやっていいのか分からないし、
ttp://www-06.ibm.com/jp/developerworks/java/040618/j_j-jtp05254.htmlとか見る限り、
今のAPI仕様でそれが完璧に行われているかというとそうでもない気がする。
どう診断すればいい医者であるか、と言う問題についてはもっと語られてもいい気がする。
433 名前：デフォルトの名無しさん mailto:sage [2007/09/03(月) 00:54:17 ]: 病気になったら即安楽死＝良い医者だと？
434 名前：デフォルトの名無しさん mailto:sage [2007/09/03(月) 00:56:05 ]: スレ誘導しようとしたらいつのまにか例外処理スレが落ちてた。
435 名前：デフォルトの名無しさん mailto:sage [2007/09/03(月) 04:46:11 ]: >>420
その程度ならRuntimeExceptionで十分
436 名前：デフォルトの名無しさん mailto:sage [2007/09/03(月) 07:58:03 ]: >>435
その程度なら throws IOException 書いておけば十分。の間違いじゃね？
437 名前：デフォルトの名無しさん mailto:sage [2007/09/03(月) 08:17:25 ]: >>435
もっかい ttp://www-06.ibm.com/jp/developerworks/java/040618/j_j-jtp05254.html 読んでくれば？
438 名前：デフォルトの名無しさん mailto:sage [2007/09/03(月) 08:53:56 ]: >>432
ロッド＝ジョンソンの本の説明が出てるな
自分も彼のJ2EE本読んで、チェック例外に対する見方を改めた口だ
439 名前：デフォルトの名無しさん mailto:sage [2007/09/04(火) 11:17:45 ]: 例外処理がもれなくSystem.exit(0)オンリーなソースを
押し付けられた俺涙目
440 名前：デフォルトの名無しさん mailto:sage [2007/09/04(火) 11:21:35 ]: 例外処理が全部 System#exit(int) ってのもアレだが、
異常終了してんのに 0戻すってのも相当アレだよな。
441 名前：デフォルトの名無しさん mailto:sage [2007/09/04(火) 11:36:48 ]: 終了するというコードが正しく実行できたので正常！
と。
曲がった先の信号が青だから曲がれる、という理屈に似てます。
>>439
まあ握りつぶされるよりはいいんじゃないか？

例外処理に関しては、パッケージ単位とか、今度出来るはずのモジュール単位で
包括して処理できる仕組みがあったら便利じゃないかなぁと思う。
442 名前：デフォルトの名無しさん mailto:sage [2007/09/04(火) 14:31:16 ]: >曲がった先の信号が青だから曲がれる、という理屈
これめちゃくちゃ危ないんだが・・・特に内輪差考えないで突っ込んで来る馬鹿な大型車とか。
443 名前：デフォルトの名無しさん mailto:sage [2007/09/04(火) 22:43:55 ]: >>439
脈絡ないけど、exit()の前にfree()は要らないってのを思い出してしまった。
444 名前：デフォルトの名無しさん mailto:sage [2007/09/04(火) 23:43:03 ]: >>432
一理あると思うが、マルチスレッドの場合はランタイム例外もきちんと
捕捉しとかないと握りつぶしたのとたいして変わらないことになるんだよな。
そのへん整合性あるガイドラインならいいんだが。

あと、安楽死というからには本当はやっぱり後始末もちゃんとしておきたいところ。
445 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 14:32:56 ]: あのfree論争ってさ、
「とりあえずfreeはしておくべき」的な教条的理想論
「どうせ終了と同時にメモリ開放するんだからいいじゃん、っていうかfreeしたって実際何もしてないのとほぼ同じだし」っていう感じの現実論
って理解でいいんだよな？そりゃ永遠に話は平行線だ罠
446 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 14:37:30 ]: 例外ってさ、単純な入力ミスで出るようなはっきりいって例外処理までしてやりたくないようなどうでもいい例外か
出てる時点でもうもうどうしようもない例外が多いような気がする
447 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 15:06:10 ]: 外部からの入力ミスなら対処しないとダメだろ。

使い捨てアプリ作ってんなら、throws Exception 付けといて良いだろうし。
448 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 15:16:29 ]: >>445
マトモな奴は、free論争なんかする暇があったら他の事をやる。
449 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 15:25:06 ]: >>445
>>448 の2つに直交する「どっちでもええがな」論があって、これが現実解。
450 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 15:46:51 ]: parseIntで数字じゃなかったときの処理を例外でやんないといけないとか、ひどすぐる。
451 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:05:21 ]: >>450
なら、どうしたら良いと思う？

parseInt の戻り型を long にして数字以外なら int の範囲外が返ってくるとか、
parseInt の戻り型を Integer にして数字以外なら null 返すとかしても、
例外よりマシになるとは思えないけど。
452 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:11:43 ]: ＞parseInt の戻り型を Integer にして数字以外なら null 返す
それやるとオートボクシングしたつもりがヌルポになったりすっからなあ

isValidInteger()みたいなチェックメソッドを作ってやるとかどうよ。二度手間だが
453 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:15:34 ]: >>452
安全なコードを書くためにそのメソッド使った
if文を書くことを強制しないといけない。

ならコンパイラでチェックしてやろうというのが
検査例外な訳で。

どこまで人間を信じるかだな。
454 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:15:42 ]: > isValidInteger()みたいなチェックメソッド
なんという銀の弾丸
455 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:18:36 ]: int[] parseInt(String)
返値は
　{ パースした数字, エラーコード }

俺もparseIntについては何とかならないかと思ってた。
parseできないってのは、想定内の状況だからExceptionにするのはどうかな、と感じてて
例外と言うより１状況として扱いたいと思ってる。
ただ、上のようにしても何かしっくり来ない。

Exception以外に、例外状況をメソッドの返りで扱えるようになればいいな、と思う。
Exception処理が重すぎるというのが元凶なんだが、
RuntimeExceptionでないものに関しては
parseIntのように、stackTraceなんて重いものは要らなくて、
その場で処理してしまう例外状況って多いじゃないですか。

何とかならないのかなぁ。
言語構造的に、Throwable一本ってのが簡単なのは分かるんだが・・・
456 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:25:02 ]: >>453
＞if文を書くことを強制しないといけない。
ここに関しては
Nullチェックに対するNullPointerException
Iterator#hasNext()に対するNoSuchElementException みたいなRuntimeException派生を投げれば済むと思うんだけど
二度手間なんだよね。このチェック。
457 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:29:35 ]: >>456
hasNextはそのチェック自体が軽いからいいけど
parseIntは、parseしちゃってるからねぇ・・・二度手間ですよねぇ・・・・
458 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:29:50 ]: >>455
> parseIntのように、stackTraceなんて重いものは要らなくて、
> その場で処理してしまう例外状況って多いじゃないですか。

parseInt の場合だと、
・ユーザー入力を parseIntした場合はユーザー入力が遅いのでExceptionが重くても問題ない。
・ファイル読み込んでparseIntした場合、パースできないケースは例外を使うべき状況なので問題ない。
だと思うが。
459 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:33:25 ]: 自己レス>>457
あ。parse結果をキャッシュできればいいのか。内部で。
って、コトは、staticメソッドじゃ駄目だな。
Stringのインスタンスメソッドになれば何とかなる、という所か・・・・
460 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:35:35 ]: >>456
要するに、検査例外だと
コードがごちゃーとするのがやだから
実行時例外にして欲しいって事でしょ？

どっちにしろ、人間をどこまで信じるかだな。
461 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:37:04 ]: >>460
paeseInt の話なら、NumberFormatException は実行時例外だが。
462 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:44:43 ]: >>455
最近の言語であるみたいにJavaが多値を返せる言語だったら良かった
んだけどなあと思う。

(int, StatusCode) parseInt(String input)

とか。

ちょっとキモイが

interface ParseResult { }
class ParseSucceed implements ParseResult { }
class ParseFailure implements ParseResult {}

というクラスを用意して、ParseResult型の値を返すとかどうだろう。
463 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:48:13 ]: >>462
後半、ただのEnumでよくね？
464 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:48:49 ]: そんなややこしいことやるくらいなら Integer を返して null かどうかで判定できればそれでいいよ
465 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:52:55 ]: >>464
だからそういうのやるとコードの変なところでヌルポが出そうで怖いんだって
オートボクシングするだけで出るし正体不明のバグ増やすだけ
466 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:56:38 ]: じゃあ @CheckForNull 付加で
467 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 16:57:55 ]: >>462
StatusCodeチェックしない場合はパースに失敗してても intの値が得られちゃうし、
その上現状よりキモくなってるしで、あんま良い事ないんじゃね？
468 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 17:02:33 ]: >>462
多値を返すという話はだーいぶ昔からBugParadeでやられてて
話に参加してみたものの結局、やらないよーという結論。

まあ、どうしてもやりたきゃ、今は配列をつかえってところ。
それなら俺は、配列に違う型を含められるようにしてくれ、と思い・・・
でも、その場合型チェックはコンパイル時には難しいわけで
Objectの配列使うのと変わらないわけで・・・・
じゃあ、じゃあstructがあったらいいんじゃ・・・・っていうと、
アレ？それってクラスじゃね？と・・・・

型チェックが緩くてもともと実行時にしか型がきまらない
スクリプト型言語なら、複数返値も考えることあんまり無くていいんだろうけどねぇ
469 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 17:24:54 ]: >>468
いやいや。型に厳しい関数型言語(MLやHaskell)などでは、
昔からタプルという形で多値が扱えたから、それと同等の
仕様にすればいいだけだと思うんだがな。
470 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 17:28:34 ]: >>463
実装は省いたけど、ParseSucceed型からはパーズ結果の値を、
ParseFailure型からは失敗の原因を取得できるようにする意図が
あったので、ただのEnumだとよくない
471 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 17:47:44 ]: >>469
>>455 だと Exception重いからException使わないようにしようって話でしょ。
タプルとか使って正常系の処理も重くしたら意味無いんじゃね？
472 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 17:55:24 ]: >>470
パフォーマンス上の理由なら、そんなもんいちいちnewして返すぐらいなら、例外投げればいいと思う。
単にコードを簡潔にしたいだけなら、
static boolean parseInteger(String text, AtomicInteger out);
みたいなのをどっかに用意してやればいい。
AtomicIntegerは、他に標準でintを参照渡しできるインターフェイスが無いからなんで、
適当なintをsetできるインターフェイスならなんでもいいと思う。

コードを簡潔にするっていっても、結局正しくパースできたかのチェックは必要なんだから、
例外で十分でしょ。
473 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 18:06:05 ]: しかし事前チェックが出来ないにもかかわらず実行時例外を投げてよろしいものだろうか
同じく文字列を解析して取得するタイプのClass#forNameが発行するClassNotFoundExceptionはキャッチ例外だよね？
474 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 20:31:41 ]: >>472
パーズ失敗というのは、自分にとっては正常系の処理なんで
例外使うのは違和感があるんだ。感覚的な問題なんだけど、
Map<K, V>#get(K key)がkeyがエントリに存在しない場合に
例外を投げられると嫌なのと似た理由で。
475 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 20:35:55 ]: >>474の補足だけど、Mapから値を取得しようとしたときにキーが存在しない場合
というのは、正常系の処理であることが多いから、もしもJavaのAPIの設計が、
例外投げるようになってたとしたらうっとおしいだろうなあということ
476 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 20:44:31 ]: parseIntの場合も、本音で言うと多値よりnull返す方が良いと思ってる。ただ、
現状のJavaでは、nullを許容する/しないを型で表現できないという欠点が
あるので、微妙なところではあるけど。
477 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 20:46:57 ]: はぁ？
478 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 20:55:41 ]: C#のNullableは安易にstructをサポートしたがために招いた失敗仕様の名残じゃないか
オートボクシングでラッパーオブジェクトと用意に相互変換可能な現状で、んなもん無用の長物
479 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 21:53:06 ]: 使用できる範囲は限定されるが
int parseInt( String numberInString, int defaultValue )があればよかった。
パーズこけたらデフォルト値を返す。
480 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 21:55:44 ]: そんなに1行で書きたいんですか
481 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 21:58:55 ]: ラッパークラスに例えばisConvertable(String)みたいなメソッドがないのがねぇ。
2回パースするくらいなら例外でいいっしょｗｗｗｗｗｗって設計思想はちょっと。。。。
482 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 21:59:23 ]: >>479
ドトネトのTryParseだな。
ttp://www.atmarkit.co.jp/fdotnet/dotnettips/408tryparse/tryparse.html
483 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 22:06:09 ]: >>482
Javaだと参照渡しがないし、標準でmutableなintのラッパークラスも無いから作りにくい。
484 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 22:08:38 ]: 俺はjava.util.prefs.Preferencesのget()を思い出した
485 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 22:13:18 ]: >>483
プリミティブを参照渡しさせない仕様なんだから
可変にしちゃったらラッパークラスにならないぞ
486 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 22:18:43 ]: >>483
つ java.util.concurrent.atomic.AtomicInteger

っても、atomicな更新のためのクラスだから
mutableなintのラッパークラスとして使うのはアレな感じもするけど
487 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 23:17:23 ]: org.omg.CORBA.IntHolder

CORBAのクラスなのがあれだが
488 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 23:25:19 ]: >>478
C#のNullableは単に値型でnull許容可能にするための代物。
俺が言ってるのは、値型/参照型区別無くある型の変数に
nullを許容する/しないを指定できる代物。しかも、nullableな型は
non-nullableの型にそのまま代入しようとしたらエラーになって
コンパイラによるチェックを強制されるようなの。具体的な言語で言うと、Nice
nice.sourceforge.net/
がそれをサポートしてる。使ってみればわかるけど、この機能はかなり便利。
489 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 23:36:14 ]: ウザいと思われるかもしれんけど、続けて書く。Niceで書くと定義はこんな感じで
書ける。

int? parseInt(String input) {//nullを含む可能性があるint型
　try {
　　return Integer.parseInt(input);
}catch(NumberFormatException e) {
　　return null;
　}
}

使用する方はこんな感じ。if(parsedValue != null)によるガードが無いと
コンパイルエラーになるのでNullPointerExceptionの心配は無い。

int? parsedValue = parseInt(inputValue);
if(parsedValue != null) {
　//parsedValueを使った処理
}
490 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 23:39:25 ]: この機能が無いからNullObjectが出来たんだな
491 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 23:45:26 ]: >>489
それ、何が嬉しいのか分からん。

parseInt だと実行時例外で例外処理を強制できないから、
nullチェック強制できる >>489 の方が良いって話？
492 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 23:47:05 ]: よく考えてみたらオートボクシングめんどくせえなｗ
これ
493 名前：デフォルトの名無しさん mailto:sage [2007/09/05(水) 23:54:52 ]: >>491
パーズ失敗を例外で扱うのに反対で、返り値でパーズ失敗を扱いたいんだけど、
nullでパーズ失敗を表すとしたらNullPointerExceptionの危険性があるし、意図が
あいまいになる危険性もある。で、この機能があればnullを許容するという事を
明示できるし、NullPointerExceptionの危険性も無いから欲しいなあということ。
494 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 00:01:56 ]: コンパイルエラーを期待してって考えなら分からんでもない。
javaならメソッド側にアノテーションで実現することになりそうだ。

@NilExclude int parsedValue = parseInt(inputValue);
if (parsedValue != null) {
// このブロック以下でのみparsedValueへはアクセス可能
}
// このスコープでparsedValueへはアクセスできない

をコンパイルすると拡張構文よろしく等価コードに展開されるみたいな感じか。

int parsedValue = 0;
Integer parsedValue$ = parseInt(inputValue);
if (parsedValue$ != null) {
parsedValue = parsedValue$.intValue();
// ...
}
495 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 00:03:19 ]: 結論はおまえにはjavaは合ってないって事だな。
話聞いてると考え方が短いコードで実現させるタイプの動的言語の発想だ。
496 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 00:04:38 ]: で、何故parseInt()のパーズ失敗を例外で扱うのに反対かというと、parseInt()は
引数から返り値が一意に定まるので、たとえパーズ失敗でも例外的な状態と
言えないと考えるから。
497 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 00:06:27 ]: >>495
なんで動的言語が関係してくるの？むしろ静的にチェックできる機能が
欲しいって話をしてるわけで、動的言語とは対極の発想だよ。というか、
短いコードが好ましいってのは動的言語特有の発想でもないでしょ。
498 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 00:07:59 ]: > メソッド側にアノテーションで実現することになりそうだ。
メソッド側にってのは余計。構成してて放置したままだった。
499 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 00:15:42 ]: 契約的言語。
500 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 00:21:29 ]: アノテーションひとつで
if (n != null) { /* n アクセス */ } と
if (n == null) { return; } /* n アクセス */
のどちらかを選択（および強制）できるのなら歓迎かな。
@Overrideの親戚みたいなもんだ。
501 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 00:43:04 ]: 例外を「例外的な状態でのみ使うべき」というのは言葉が同じだからもっともらしく
聞こえてしまうだけで、何の助けにもならない方針。

www.boost.org/more/error_handling.html
boost.cppll.jp/HEAD/more/error_handling.html
502 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 00:48:46 ]: >>500
FindBugsをどうぞ
findbugs.sourceforge.net/manual/annotations.html
503 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 01:03:12 ]: >>493,496
単に自分の考えと合わないってだけ？
それって自前のクラスメソッド書いて、そっち使うんじゃダメなんか？

なんつーか、>>448-449 あたりが結論になりそうな話じゃねーかと。
504 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 01:14:56 ]: >>503
もちろん自前のクラスメソッド書いて使うことになると思うよ。
実際にJavaプログラム書くときの解決策としては。単に言語の
拡張まで含めて許されるならどういう設計にするのが良いかという思考実験。

あと、free論争とは文脈が違うので一緒にされるのはちと心外だな。
どういう方針でライブラリ設計をするかという話は使い勝手に関わって
くる。もちろん、ここで議論しても実際のJava APIの設計が改善されない
という意味では無益なのはそうだけど。
505 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 01:26:05 ]: >>496
理解できない
すべての失敗する引数はnullが返ることで一意に定まるということ?

例外的な状態かどうかはparseInt単体でなく、呼出し側がどうしたいかでも異なるはずだ
デフォルト値が定まる場合と定まらない場合、とか
んで、とりあえず保守的にパーズ失敗を例外として扱うと言う設計でよいと思う
checkedかどうかは微妙なとこだが
506 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 01:26:52 ]: 単に好き嫌いの問題で、パフォーマンスとか関係ないんでしょ？
free論争と大して変わらんと思うが。
507 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 01:30:33 ]: >>504
parseInt の使い勝手を改善する事により、Java での開発効率が 10％向上するんだ！
とか考えてるなら一生懸命考えるのも頷けるんだけど……

ぶっちゃけ瑣末な問題じゃね？
508 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 01:40:40 ]: 例外を握りつぶすユーティリティメソッド作ればOK。
509 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 02:03:58 ]: >>505
> すべての失敗する引数はnullが返ることで一意に定まるということ?
そういう意図で書いた。正確に言うと、外部の状態に依存せずに
入力*のみ*から返り値が決定される、ということ。その逆の
典型的な例としてはIOExceptionを発生させるような関数や
コンストラクタがある。これらの関数は入力だけでなく外部の
状態によって成功したり失敗したりする。

>>507
parseIntだけの問題として考えればぶっちゃけどうでもいいけど、
一般的な問題としてある関数が失敗を返り値で通知するか
例外で通知するか、というのは瑣末な問題じゃないと思う。
510 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 09:42:29 ]: ユーティリティメソッド作ればOKってのは、思考停止以外のなにものでもない。
511 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 09:46:39 ]: parseInt を改変しようとか考えるのは暇人以外のなにものでもない。

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef