[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/ 347 名前：デフォルトの名無しさん mailto:sage [2007/08/22(水) 11:31:10 ] 分割ロードの方が良さそうだなあ。 Javascriptは何でも一つのファイルにぶち込むのが流行ってきているけれども。 348 名前：デフォルトの名無しさん mailto:sage [2007/08/22(水) 14:09:41 ] >>345 Java Kernel と呼ばれているものを jdk6 update 4 で出す予定 weblogs.java.net/blog/enicholas/ weblogs.java.net/blog/forax/archive/2007/08/java_kernel_in.html 349 名前：デフォルトの名無しさん mailto:sage [2007/08/22(水) 14:24:44 ] >>344 Date と Calendar はコンストラクタ一発で変換できてないじゃん。 それと同じ事が起こる事は十分予測可能。 350 名前：デフォルトの名無しさん mailto:sage [2007/08/22(水) 14:30:23 ] >>349 っつーか、コンストラクタ一発で変換できても煩雑なのは変わらんのだがな。 351 名前：デフォルトの名無しさん mailto:sage [2007/08/22(水) 20:01:17 ] ”よく知られた日付型”がこれ以上混在されてもうざいだけだよ。 DateにCalendarにsql.Dateと、”よく知られた日付型”は、もう既に食傷気味です。 所詮は64bit unix epocと割り切ったユーティリティメソッドが拡充される方がよほど嬉しい。 352 名前：デフォルトの名無しさん mailto:sage [2007/08/22(水) 21:21:02 ] なるほど。 良くあるパターンに特化したユーティリティメソッドを用意してくれる方が ありがたい気がする。 353 名前：デフォルトの名無しさん mailto:sage [2007/08/22(水) 21:49:03 ] JREのインスコなんてウィザードに従えば良いだけだろ。 それより、システム管理全体がside by sideへ以降してきてメンテにエンドユーザーの負担が掛かってると思う。 354 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 01:19:58 ] JSR 310はいいと思う。 ユーティリティ・クラスとしても上出来。 355 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 03:08:43 ] >>354 そうなん？ >>310 に JSR-310 のAPIリファ来てるけど、 これどんな時に便利なのかサンプルコードとか書いてくれん？ っつか、オレには Moment や Period のサブクラスが 年、月、日、時、分、秒と分かれてる必要性がイマイチわからん。 356 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 04:03:13 ] タイムベースの処理が必要でそのフレームワークを自前で作らなきゃいけないときに下のライブラリとして使えそうだな。 357 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 04:06:51 ] >>310がJSR-310のリンクになっていることに 今になってようやく気が付いた。 なんか黄色ナンバーの車を1日10台見たとか ワーゲン見たとかその程度にちょっと幸せ。 358 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 08:11:21 ] >>355 ぶっちゃけ、>>310より>>331の方が良いと思う…… 359 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 08:43:24 ] >>356 逆に言うと、それ以外の目的に使えなさそうじゃね？ 360 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 08:46:22 ] どっちがいいとかそういうもんじゃないだろ。 310はベースとなる時刻クラスを提供するんだから。 361 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 08:49:25 ] 今のままだったら Date ＆ Calendar の方が下位層で JSR-310 はそれに乗っかるだけの上位層になりそうだが 362 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 08:50:20 ] （　ﾟдﾟ）ﾎﾟｶｰﾝ 363 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 08:52:26 ] おまけに使用用途が酷く限定されている、と。 364 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 09:01:34 ] >>360 んじゃ言い直そう。 JSR-310 のスライドにあがってる、 What is wrong with Date and Calendar? の解決策としては、今のところ>>331の方が良さそうに見える。Date の Could not be successfully localized とか Most methods deprecated、 SimpleDateFormat の Calendar cannot be directly formatted は解決できそうだ。 365 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 09:25:39 ] >>360 310が提供するベースとなる時刻クラスってどれよ？ 366 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 11:36:39 ] 文字列からのファクトリメソッドは、 別クラスにした方がいいんじゃないの？ L10N考えると劇重プロジェクトだし。 GNU dateコマンドみたいな時間指示を考えると、やること一杯ある。 367 名前：デフォルトの名無しさん mailto:sage [2007/08/23(木) 11:46:17 ] これはひどい ベースとなる時刻クラス・・・ Instant かねぇ でも CalendarDay や TimeOfDay との相互変換はできそうになく 既存の Date や Calendar との繋がりもない どうやって使うんだこれ 368 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 00:25:02 ] 310はまだ、かなりドラフトな感じだが、 PeriodとMomentとその実装クラスを細かく分けるのは、 安全でかつ読みやすくなるのでよいと思う 例えばMomentにMomentは追加できないがPeriodは追加できるとか 369 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 01:23:17 ] Instant と fully defined な SingleMoment を区別する理由と、 Period と Interval を区別する必要とか、 Duration とか良く分からん。 Duration と Inteval はまだ出来てないみたいだけど。 >>368 も同意っちゃ同意なんだけど、 それって Moment と Period が別になってる理由にはなっても、 Moment や Period のサブクラスが 年、月、日、時、分、秒と 細かく分かれてる理由にはならんよね。 370 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 01:58:25 ] >> 369 >Moment や Period のサブクラスが 年、月、日、時、分、秒と >細かく分かれてる理由にはならんよね。 なんで? Days days = ...; days = days.plus(Days.days(3)); とか具体的な型が決まっていたら安全かつ読みやすいじゃん。 しかしメーリングリストだとなんかいろいろ提案とか出されたり、まだまだな感じがしてきた。 sunの中の人が書いてるが、 blogs.sun.com/yk/date/20070705 既存のAPIとの互換性とか国際化も考えると大変そうだね。 371 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 02:02:32 ] >>369 後者については type safe のためとか？ もしくは、 Moment moment = build(dayOfMonth(1), hourOfDay(3)); とかやると、毎月 1日午前 3時 をあらわすようになるとか…… 372 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 02:05:26 ] >>370 おいおい…… 一見型安全かもしれないけど、 それだけだと、逆に Period で 1カ月と3日とか複合的な指定できなくなるんですけど…… 373 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 02:10:03 ] >>371 あぁなるほど。可変長引数のビルダーメソッドで纏めるとか そーゆー場合には別々のクラスになってないとダメだな。 >>370 これはひどい 374 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 02:34:16 ] >>372 Periodとしての一ヶ月というのは日数として組み合わせて扱えない気がするが。 375 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 02:37:46 ] （　ﾟдﾟ）ﾎﾟｶｰﾝ 376 名前：374 mailto:sage [2007/08/24(金) 02:48:29 ] 今のAPIを見る限り、複数のPeriodを組み合わせたPeriodというのはない気がする。 Monthsに関しては月によって日数は変わるので、months.plus(Days.days(3))みたいな計算は書けないと思うが。 しかしCalendarDayはplus(Period...)というのを持ってるので、一ヶ月と3日後とかを計算できると思う。ただMinutesとSecondsとの変換とかできそうな気がするのにできないように見えるのはよくわからない。 377 名前：デフォルトの名無しさん [2007/08/24(金) 02:51:08 ] >>372 そーゆーのは、まだない Interval でやるって話なんじゃね？ しっかし、凄く分かりにくい API だな、これ。 そこそこ経験がある奴でもサンプルコードが無いと一行も書けないぞ。 378 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 02:55:09 ] >>373 instanceof で比較するところを enum と switch で置き換えれば 良いだけだから、別々のクラスになってる必要は全くなかったりする。 379 名前：374 mailto:sage [2007/08/24(金) 03:03:40 ] やっぱりわかりにくいのだろうか? 変換とかファクトリとかのメソッドがどこにあるかわからず、分かりにくい、というのはあるかもしれないが、 そもそも日付と時間の長さなどを区別して扱うこと自体が複雑で、結局intとかで扱っても値の種類を把握していないといけないのでは。 ある程度、単位を型でエンコードして分かりやすくすることで安全で読みやすいコードになる方がよいと思うのだが... 380 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 05:59:11 ] Sun が NASDAQ での銘柄記号を SUNW から JAVA にかえるんだそうな。 blogs.sun.com/jag/date/20070823 blogs.sun.com/jonathan/entry/java_is_everywhere いや、次世代Javaと関係ないけど。 っつーか、これジョークじゃないの？ 4月1日じゃないけどさ。 381 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 07:09:27 ] Dateみたいな基本的なところに今から手を入れるのがアリなら、 Numberもどうにかしてくれんかな。 やっぱり Integer inherits Double であってほしいし、BigDecimalで 持っている四則演算メソッドはNumberすべてで使いたいが。 382 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 07:17:34 ] >>380 JAVAの株があがったとか下がったとかが問題になってくるわけか。 そしたら、JAVAと大文字で書くやつはJavaのことを知らないという伝説が強くなるわけだ。 383 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 07:43:01 ] >>381 Numerics関係は難しいんだよな、後からいじるの。 非互換の影響が大きすぎて。 仕様お目付け役だった、Guy Steeleさん、この辺が弱い。 384 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 16:04:46 ] 元がSUNWならJAVAWにすればいいのにコンソール出ないし・・・。 385 名前：デフォルトの名無しさん mailto:sage [2007/08/24(金) 16:57:17 ] >>381 メソッド追加はありでも継承関係は変えられないだろうな 386 名前：デフォルトの名無しさん [2007/08/29(水) 21:26:22 ] そろそろ deprecated のクラスやメソッドを一掃してほしい 387 名前：デフォルトの名無しさん mailto:sage [2007/08/29(水) 22:30:24 ] Cloneable を Clonable に直してほしい 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 付けといて良いだろうし。

---

---

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

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