- PR -

JAVA言語の作法について

«前のページへ 1|2|3|4|5 次のページへ»
投稿者投稿内容
masa
大ベテラン
会議室デビュー日: 2005/05/11
投稿数: 108
投稿日時: 2005-09-21 16:29
こんにちは。

例外補足時に行える処理がないならば、catchは必要ないかと。
↓catchを省略してこの形で
try {
処理
} finally {
後処理
}

冗長なcatchは潜在的なバグの要因となりえますので、(throwの記述漏れなど)
なるべく書かない方が無難かと思います。
（この辺は好みが分かれる部分なのでしょうか？）

それとthorwsの定義は
throws IOException,FileNotFoundException
となっていた方が使用する側から見ると分かりやすいですね。
クラスの使用者がFileNotFoundExceptionをcatchした時に復帰処理を行える可能性
がありますので、明示的に記載されていた方がありがたいです。
じゃんぬねっと
ぬし
会議室デビュー日: 2004/12/22
投稿数: 7811
お住まい・勤務地: 愛知県名古屋市
投稿日時: 2005-09-21 16:37
こんにちは、じゃんぬ です。

引用:

masaさんの書き込み (2005-09-21 16:29) より:

冗長なcatchは潜在的なバグの要因となりえますので、(throwの記述漏れなど)
なるべく書かない方が無難かと思います。
（この辺は好みが分かれる部分なのでしょうか？）

CodeComplete では空の catch 句は CODING HORROR となってました。
理由は masa さんが提示してくださった通りです。
どうしてもという場合でも、せめてエラー出力だけはしてスルーでしょう。


_________________
C# と VB.NET の入門サイト
じゃんぬねっと日誌
kuma
大ベテラン
会議室デビュー日: 2004/02/25
投稿数: 110
投稿日時: 2005-09-21 16:48
引用:

あしゅさんの書き込み (2005-09-21 00:40) より:
引用:
kumaさんの書き込み (2005-09-20 20:12) より:
どうせなら
breader.readLine()
をStringBufferに溜め込んでwhileを抜けた後、一気に書き出すようにしたほうが
Exceptionの個所も判別つき易くなってよくないですか？


ストリーム上で処理を完結できるのに、全体をメモリ上に展開するのはあまり
よろしくないのではないでしょうか。特に連続メモリとなる場合は危険です。
基本的にストリームの長さを仮定するのはよろしくないかと。

＃編集された部分がこのあたりだったらごめんなさいです。


編集したのは別部分です。

write(String)
でその都度エンコードされていませんか？
何行あるか未知のものを毎回エンコード処理させるほうがキツイ気がしたので・・

nullは普通に
if (reader != null)
reader.close();
だけでよいのでは？
close()があるものにわざわざ
reader = null;
とは、しない気がします。
また
reader == null
のときは他の判別ではともかく
close()するかしないかのチェックでは
何もしないままで問題ないでしょう。
unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)
投稿日時: 2005-09-21 18:13
unibon です。こんにちわ。

引用:

kippleさんの書き込み (2005-09-21 15:34) より:
略
reader = new BufferedReader(new FileReader(inputFileName));
writer = new BufferedWriter(new FileWriter(outputFileName));
略
}finally{
writer.close();
reader.close();
}
略

このコードだと BufferedWriter の中でエラー(ディスクフルなど)が起きたときに、関連付いているファイルリソースを close できないときがあります。BufferedWriter の close のソースコードを見ると、close する前に flushBuffer しているためです。flushBuffer の中で例外が発生すると close しないままになってしまうはずです。
このような異常時には BufferedWriter を close するのではなく、FileWriter を close すべきだろうと思います。
なお、Reader のほうは大丈夫なのかもしれませんが、対称性を考えると Writer と合わせておくほうが無難かもしれません。

＃以下、あとで追加。

ガーベッジコレクションが動けば、ファイルリソースは解放されるでしょうが、それまでの数秒〜数十秒間は解放されないままになります。

[ メッセージ編集済み 編集者: unibon 編集日時 2005-09-21 18:14 ]
vincent
大ベテラン
会議室デビュー日: 2004/07/09
投稿数: 142
投稿日時: 2005-09-21 19:04
文法を知ってコンパイルできて動けばOKというのではなく、その言語独特の
作法や流儀を勉強しようとする姿勢はすばらしいですね。

ところで、BufferedReaderの行取得ロジックは
while (reader.ready()) {
　　String s = reader.readLine();
　　//以下略
}
のほうがスマートだと思うのですが、これって何かまずいんでしたっけ？
未記入
ぬし
会議室デビュー日: 2004/09/17
投稿数: 667
投稿日時: 2005-09-21 20:09
引用:
ところで、BufferedReaderの行取得ロジックは
while (reader.ready()) {
　　String s = reader.readLine();
　　//以下略
}
のほうがスマートだと思うのですが、これって何かまずいんでしたっけ？

Reader.ready() は、ストリームに 1バイトでもデータがあれば true を返します。つまり、ready() を確認することによってブロックしないことが保証できるのは read() くらい。readLine() は、改行までを読み取る必要があるので ready() が true を返してもブロックする可能性があります。

つまり、readLine() の前に ready() を確認するのは、あまり意味がありません。
masa
大ベテラン
会議室デビュー日: 2005/05/11
投稿数: 108
投稿日時: 2005-09-21 23:03
こんばんは。

引用:

じゃんぬねっとさんの書き込み (2005-09-21 16:37) より:
CodeComplete では空の catch 句は CODING HORROR となってました。
理由は masa さんが提示してくださった通りです。

CodeComplete という本の存在は初めて知ったのですが、ネット上の評判を見る限り
かなりの名著のようですね。出版された時期は少々昔のようですが、今読んでみても
時代遅れではない内容でしょうか？
購入してみようかなぁと考えていますので、教えて頂ければ嬉しいです。

脱線してすいません
ちいにぃ
大ベテラン
会議室デビュー日: 2002/05/28
投稿数: 244
投稿日時: 2005-09-22 02:01
2005/3/28に第2版が出版されてて、@IT BOOK Preview: Code Complete 第2版で一部分だけ読めます。
«前のページへ 1|2|3|4|5 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）