著作一覧 |
どーしてJavaにはチェック例外があるのか、でも良い。
すべてのチェック例外が無意味というわけではなく間違いなく必要なのはリソースの後始末が必要系のやつ。
Connection con = null;
Statement s = null;
try {
con = dataSource.getConnection();
s = con.createStatement();
s.executeUpdate("drop table bangbang");
} catch (SQLException e) {
// エラーになった
} finally { // (A)
if (s != null) { try { s.close(); } catch (SQLException e){} } // (B)
if (con != null) { try { con.close(); } catch (SQLException e) {} } // (C)
}
(A) …… 忘れるとやばやば。
(B), (C)……うざったいな、もう。
ということから、closeだけ非チェック例外にしてくれりゃ良いのだが、その前の段階ではチェック例外にしておいたので、イヤでも後始末を気にするかも知れない。
public dropBangBang() throws Exception { // 気にしない人
....
}
とすることもできるけど。
その意味では
Connection con = null;
Statement s = null;
try {
con = dataSource.getConnection();
s = con.createStatement();
s.executeUpdate("drop table bangbang");
s.close();
con.close();
} catch (SQLException e) {
// エラーになった
}
は、ブァカですかと言われてもしょうがないのだが。
ところが、C#にはチェック例外が無い。
これは、(B)(C)は楽チンだが、(A)の部分の歯止め効果まで失うのではないか?
さすがMSですなぁ、抜けてますなぁ、なのかと言うと、そのかわりにusingがあるんじゃないかと気付いた。どっちにしても呼ばない人は呼ばないわけで、ここは歯止めの有無が論点だから、usingで良いのだ。
using (SqlConnection conn = new SqlConnection("Initial Catalog=Northwind;Data Source=localhost")) {
SqlCommand cmd = new SqlCommand("drop table bangbang");
cmd.Connection = conn;
conn.Open();
cmd.ExecuteNonQuery();
}
こっちのほうが好きかも。(例外は上位モジュールで捕捉)
なぜ、パッケージプライベートがデフォルトか?
で、ふと思ったのは、1publicクラス=1ファイル縛り。これは、C++なんかのソースファイルより相当狭い。
実際には、1パッケージ1クラス(+該当クラスに関連する0〜5くらいを限度としたクラス)=C++での1ソースファイル(staticスコープの範囲)というようなのを想定していたのではないだろうか、とか。
とは言うもののJ2SEのパッケージとかでかいんだけど。
ただ、そう割り切れば原理的にはprivateというのは余り使う必要は無さそうで、アクセス修飾子はデフォルトとpublicと、たまにprotectedくらいになるから間違いは少ないかも。
そうすると、パッケージを分けなさいというほうが、privateの記述をデフォルトとさせるよりも、コード上のルールは少なくなるから良いかもなぁ。
ジェズイットを見習え |