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

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/ 388 名前：デフォルトの名無しさん mailto:sage [2007/08/30(木) 02:13:33 ] creat.... 389 名前：デフォルトの名無しさん mailto:sage [2007/08/30(木) 23:47:25 ] catch必須例外を堂々と無視できるプラグマを追加してほしい。 390 名前：デフォルトの名無しさん mailto:sage [2007/08/31(金) 03:25:48 ] アホか例外処理の意味ないだろ。 握り潰すことすら面倒くさいか？ｗ 391 名前：デフォルトの名無しさん mailto:sage [2007/08/31(金) 12:32:21 ] JDK7 build19 ttp://www.java.net/download/jdk7/changes/jdk7-b19.html ttp://download.java.net/jdk7/binaries/ forumで話題になっていた 4811096 Allow mixing of heavy and lightweight components が入った様子。 SwingとAWT混ぜるなっていうのが古い話になるわけだ。 あと、レポジトリ管理、Teamwareを完全撤廃？SCCSキーワードの削除ってのが結構あった。 公開してるのも、Subversionでだしね。OpenSolarisで採用してる、Mercurialはないんだろうか？ 392 名前：デフォルトの名無しさん mailto:sage [2007/08/31(金) 21:15:56 ] >>390 めんどくさい。 どうでもいいコンソールプログラム書くときは 全部例外がトップレベルに流れて死んでくれていい。 あと、どうせならインタフェースの実装も堂々と無視できるプラグマも欲しい。 適当にnullとか0とかfalseとか、あるいはNotImplementedException投げるとか。 IDEにやらせればいいんだけどさ。 393 名前：デフォルトの名無しさん mailto:sage [2007/08/31(金) 21:52:53 ] >>392 お前はCの方が合ってるんじゃないか？ つーかその程度の捨てアプリならスクリプトで実装すれば良いだけじゃん。 394 名前：デフォルトの名無しさん mailto:sage [2007/08/31(金) 22:32:46 ] mainメソッドにthrows ExceptionってすればOK 395 名前：デフォルトの名無しさん mailto:sage [2007/09/01(土) 02:07:00 ] Javaの例外処理の面倒くささはMatzがどっかで言及してたね 396 名前：デフォルトの名無しさん mailto:sage [2007/09/01(土) 02:21:10 ] silentClose(Closeable) みたいなメソッド作るとか 使い捨てアプリ作る時は throws Exception つけるとかすれば そこそこ改善すると思うんだけどね 397 名前：デフォルトの名無しさん mailto:sage [2007/09/01(土) 02:29:38 ] >>395 むしろその例外処理の面倒さがないからこそ 他の言語があぶなっかしくて使えない。 コード品質重視だと特に。 398 名前：デフォルトの名無しさん mailto:sage [2007/09/01(土) 06:37:06 ] むしろ投げる例外をdoc,code上で明文化されてないと何拾って良いか分からないだろ。拾えないと例外に対処できない。 throw,throwsでthrowable以外が飛んでくるのもおかしいし。 399 名前：デフォルトの名無しさん mailto:sage [2007/09/01(土) 16:45:03 ] ExceptionはThrowableである。以上。 400 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 09:52:45 ] 例外処理の仕組みが問題というよりも IOExceptionとかSQLExceptionのようなレベルの例外を チェック例外にしてるのが問題だと思う SpringやS2やHibernateなら、これらの例外をランタイム例外にラップしてくれるし JavaEE5ではランタイム例外を多用してるけど 肝心の、JavaSEのコアなAPIがチェック例外だらけだからな >>397 現実には、Javaのチェック例外記述のめんどくささに嫌気がさした開発者が catch (Exception e) { e.printStackTrace(); } とか書いて、返って品質悪化するパターンの方が高い気がするorz 401 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 11:41:41 ] あと InterruptedException も握りつぶされて困りやすいチェック例外だ あー InterruptedIOException とか、きっと知らんうちに IOException もろとも握りつぶしてる気がしてきた try { ...... } catch (InterruptedIOException e) { Thread.currentThread.interrupt(); } catch (IOException e) { ...... } なんて、書いた覚えがないよ 402 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 11:50:49 ] 例外のためのEffective Javaみたいなのがあれば読んでみたい。 こういうのはお習字の世界だから仕様としてどうこう変えるもんでもないし。 403 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 13:29:09 ] >>400 IOExcepotionとかは>>396みたいなメソッドがあれば解決する問題 後半に関して言えば そーゆー奴は面倒くさいので例外処理しないし 他人のために必要な例外関連のドキュメントも書かない ので検査例外をあってもなくてもそれほど品質は変化しないと思うが 404 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 13:39:45 ] 何が言いたいのやら・・・必死なことだけは解るが 405 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 13:48:59 ] IOExceptionやSQLExceptionがチェック例外なのは当然だろ？ 外部リソースに依存してんだから、チェックし無い方がどうかしてる。 DAOならそれらをcauseにして、DAOExceptionみたいに新たなチェック例外にくるむがよろし。 406 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 13:55:57 ] closeが例外なげるバカなAPI 407 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 14:04:03 ] close は flush を伴うからエラーが発生する可能性はある 408 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 14:07:19 ] closeが例外なげるのがバカってどんだけゆとり脳なんだ 409 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 14:14:18 ] 思うに、チェック例外をキャッチしないと 警告出すだけの仕様だったらどうなっていただろうか？ 410 名前：デフォルトの名無しさん mailto:sage [2007/09/02(日) 14:26:33 ] throws SQLException って書いてないのに throw new SQLException() するような 混ぜるな危険メソッドが書き放題で検査例外の意味がなくなる。 それでいてソースに SuppressWarnings("ignorecheckedexception") とか コンパイル時に -ignorecheckedexception とか必須だと手間がかかるだけ。 中途半端で役に立たないソリューションの見本だな。 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/ がそれをサポートしてる。使ってみればわかるけど、この機能はかなり便利。

---

---

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

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