- 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/
- 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 を改変しようとか考えるのは暇人以外のなにものでもない。
- 512 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 09:53:09 ]
- >>511
そうか？
- 513 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 10:14:54 ]
- >>511
つきあってた連中も暇人以外のなにものでもない。
- 514 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 11:20:14 ]
- 改変は、ちゃんと考えてbugparadeにあげるなどすれば、なにがしかの影響は与えられる。
ここで改変について語るのも、そういったヤツのインスピレーションになることもあるだろうし、本人が書き込むこともあるだろう。
無駄ではないよ。
- 515 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 11:39:06 ]
- なにがしかの影響って……
>>509 も parseInt に関してはどうでもいいって言ってるんだが。
そんな瑣末な問題に関わらせる事で
JDK開発者のモチベーションを下げたいって事か？
free論争ってさ、やってる当事者は引っ込みがつかなくなってるだけかと思ってたけど
案外、>>514みたいに「この議論は無駄ではない」とか思ってる人も居るのかも知れないね。
- 516 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 11:41:41 ]
- parseIntの例外が例に挙がって
- コードを短く書きたい
- 例外で扱う状況とは思えない
という2点の争点があると思う。
さらに後者の視点は、
- 例外を扱うべき状況を設計の美しさから考える
- 例外を扱うべき状況をException処理の重さから考える
という2つの立場がある
俺は、parseIntに例外の記述が出てきてもいいが、重いException処理が
いやだなぁ、という点から、こういうのがあればいいんじゃないかと思う。
定義済Exception/ StaticException / 短距離Exception /LightWeightException ?
今、Exception処理が重いのは、Exceptionオブジェクトの生成にある（スタックトレース生成など）
つまり、生成処理をなくしてやれば大幅にパフォーマンスは改善するはず。
なので思い切って、stackTraceとかが空っぽのExceptionで
すぐ直上のcatch節で捉える決まりで、
さらにThrowの必要があるときは別のExceptionにしなくてはいけないようなもの。
気軽に例外が投げられるようになって、正常系の処理が例外でトリッキーに実装されるように
なっちゃうかもしれないけど、こういうのってどうですかね。
- 517 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 11:47:27 ]
- >>515
相手にするから調子に乗るんだろ。ほっとけ。
- 518 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 12:05:24 ]
- >>516
> 重いException処理がいやだなぁ、という点
いやなだけなのか。
これこれこういう使い方をすると、
（パーズ失敗する）parseInt の呼び出しがボトルネックになって困る、
そして、このような使われ方をする事が多いので標準APIを改善して欲しい、
ってんなら議論の余地もあるけど、それって単なる好き嫌いの問題じゃね？
- 519 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 12:39:29 ]
- >>518
包丁一本で、何でも作るのって大変じゃないかな、って話です。
sourcepost.sytes.net/sourcepost/sourceview.aspx?source_id=29658
のコード書いて、Exception生成のコストを見てみました。
ウチのマシンでの結果です（かかった時間）
Try[1]:422
Try[2]:10469
Try[3]:78
Try[4]:10875
１つめが、Throwableを継承して、Overrideで色々ぶった切ったクラス。
２つめが、単なるException。
３つめが、単なるObject。
４つめが、NumberFormatException。
Objectのnewに比べて、Exceptionのが大幅に重い処理となっています。
NumberFormatExceptionもそうです。
もし、ファイルを読む処理をするときに、数字でないものも大量に含むフィールドがあれば
Exception処理が時間を食うことが予想されます。
Exceptionの機能を大幅にカットすれば、２桁のオーダーで処理を軽くすることができるわけです。
現在の仕組みを使って、実装するならこうなりますがシステムとしてサポートしてくれても
いいかなぁ、と思ったわけで。
- 520 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 12:53:24 ]
- >>519
> 数字でないものも大量に含むフィールドがあれば
普通はフォーマットエラー吐いて終わりでしょ。
- 521 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 13:10:14 ]
- 〃〃∩ _, ,_
⊂⌒（ `Д´） ＜ ヤダヤダ！ parseInt が例外使っちゃヤダ！
｀ヽ_つ ⊂ノ
ジタバタ
〃∩
⊂⌒( _, ,_） ＜ ぶっちゃけどうでもいいけど、やっぱりヤダヤダ……
｀ヽ_つ ⊂ノ
ﾋｯｸ...ﾋｯｸ...
⊂⌒( _, ,_）
｀ヽ_つ ⊂ノ zzz…
- 522 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 13:56:24 ]
- delphiのStrToIntDefみたいに、数値にできないときのデフォルト値が指定できればかなりいい
- 523 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 14:17:51 ]
- >>520
何で？全部読んで例外をチェックしないと駄目かもしれないですよ。
いや、というか例外を使うなとかいう話ではなく、
パフォーマンスを気にして例外を使うべき場面を回避しようとするのは
本末転倒だから、例外を使わなきゃ駄目なときパフォーマンスが
落ちなければそういう誤解、というか誤用がなくなるんじゃないかと。
- 524 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 14:45:35 ]
- >>523
「かもしれない」って……
要するに、今現在（パーズ失敗する）parseInt の呼び出しが
ボトルネックになって困ってるわけじゃないんでしょ。
単なる好き嫌いの問題にしか見えないが。
それに、誤用とか誤解とか言われても……
>>509の理論が いつでもどこでも通用する例外のガイドラインとはとても思えないし、
使い勝手、堅牢性、パフォーマンス、好き嫌いとか色々な要素が絡んでくるから
いつでもどこでも誰にでも通用する例外のガイドラインを作るのは難しいだろうし。
- 525 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 14:47:32 ]
- ということは例外はこれまでどおりフィーリングとわずかなドキュメントで判断していくしかないのかね
- 526 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 15:21:46 ]
- >>524
>>523 ≠>>509です。
parseIntはあくまで例です。
確かにちょっと誤解されそうなレスでした・・・
誤用というのは、Exceptionを使うまいとして
ごちゃごちゃとしたコードになってしまうような状況を指してます。
具体的にカチッとした基準に基づいた「ごちゃごちゃ」ではありませんが。
私は、parseIntに関わらず、Exception処理が軽くなればいいな、という話をしているつもりでした。
- 527 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 15:36:41 ]
- >>526
parseInt で例外生成コストが下がると嬉しいか？
それに、parseInt で Exceptionを使うまいとして
ごちゃごちゃとしたコードになるって、どんな状況？
あと、俺は Exception処理が軽くなれば良いって要望に対する返答が
「例外的な状況以外で例外使うな」って話なんだと理解してるんだが。
例外って濫用すれば goto より悲惨なスパゲッティコード書けるしね。
- 528 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 17:31:04 ]
- パースの失敗は十分、例外的状況に値すると思うが・・・。
例外処理の乱用がスパゲッティーコード招いてるんじゃなくてそういうコード書いてる自分がスパゲッティー作ってるんだと思う。
アプリケーションかミドルウェア側の設計でどうにかなると思うんだが？
- 529 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 17:37:48 ]
- >>527
InterruptExceptionって例外的だと思う？
スレッドのキャンセルを実装しようと思ったら普通に出るけど
- 530 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 18:49:35 ]
- >>528
設計っつーか、実装で吸収できるでしょ。
- 531 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 20:19:45 ]
- 便利なら便利なほうがいい。
- 532 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 20:24:49 ]
- 何を便利と感じるかは人によって違う、と。
かと言ってなんでも標準APIに入れたら標準APIメンテする人間の負担が増えて
バグが増えたり放置されたりといった悪影響も考えられる、と。
- 533 名前：デフォルトの名無しさん mailto:sage [2007/09/06(木) 20:47:42 ]
- NICEのnullableってのは興味深いネタだったけど、
それと一緒に語られたparseIntの仕様には何の興味も湧かなかった。
つーことで、イディオム補完型（保証型）のアノテーションの充実を期待したい。
- 534 名前：デフォルトの名無しさん mailto:sage [2007/09/07(金) 07:32:33 ]
- >>445
終了前のfreeは害っていうのがいるだろ。
- 535 名前：デフォルトの名無しさん mailto:sage [2007/09/07(金) 07:55:31 ]
- そんなものは無い
- 536 名前：デフォルトの名無しさん mailto:sage [2007/09/07(金) 22:37:51 ]
-
blogs.wankuma.com/kacchan6/archive/2007/09/07/94499.aspx
- 537 名前：デフォルトの名無しさん mailto:sage [2007/09/07(金) 22:39:06 ]
- blogs.wankuma.com/kacchan6/archive/2007/09/07/94499.aspx
- 538 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 00:14:55 ]
- parseIntで100近くもダベれるお前らに脱帽
- 539 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 00:53:35 ]
- >>536
低脳な質問で悪いんだけど
「クリティカルで速度が要求される場面での数値チェックは、例外を使わないのが無難っぽいです。」
って言ってるけど、じゃぁどういう処理が望ましいんだろうな。
俺も、試しに同じ用なプログラムを10000000回処理をぶん回してみたが、
正直それほど有意差は認められなかった。
----以下結果----
StringUtils.isNumeric() : boolean で不正な文字かどうかを検知
1回目 451 ms
2回目 401 ms
Integer.parseInt() : 例外で不正な文字かどうかを検知
1回目 42822 ms
2回目 42771 ms
- 540 名前：デフォルトの名無しさん [2007/09/08(土) 01:03:04 ]
- >>539
例外を使ってるバージョンが100倍近く遅いんだが、それは
有意な差じゃないの？
- 541 名前：デフォルトの名無しさん [2007/09/08(土) 01:05:19 ]
- あ、もちろん実際にparseIntが使われる局面で1000000万回も
呼ばれることは無いだろうから、そういう意味では例外を使っても
いいんだろうけど、有意な差が無いってのは変でないの？ってこと
- 542 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 01:05:27 ]
- >>539
ネタにマジレス。
まず 数値チェックに parseInt 使って
> クリティカルで速度が要求される場面
が具体的にどういう場面なのかってのを特定するのが先決。
それをしないで「どういう処理が望ましいか」を考えても時間の無駄。
- 543 名前：デフォルトの名無しさん [2007/09/08(土) 01:07:45 ]
- 間違った。1000000万回 -> 1000万回
- 544 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 01:12:44 ]
- >>538
まだまだ続くよ
- 545 名前：デフォルトの名無しさん mailto:sage [2007/09/08(土) 01:59:22 ]
- 巫女巫女ナース巫女巫女ナース♪
|
 |
