Rebel without a clause: 5 ways to misuse exception handling
Introduction
Do you consider yourself a Java expert?
あなたは自分を Java のエキスパートだとみなしていますか?
Think you know everything about exception handling ?
自分は例外処理について何でも知っていると考えていますか?
Can you quickly spot five exception handling problems below?
以下のプログラムにある例外処理に関する問題点を五つ、即座に指摘できますか?
OutputStreamWriter out = ...
java.sql.Connection conn = ...
try {
Statement stat = conn.createStatement();
ResultSet rs = stat.executeQuery(
"select uid, name from user");
while (rs.next())
{
out.println("User ID : " + rs.getString("uid") +
", name : " + rs.getString("name"));
}
conn.close();
out.close(); }
catch(Exception ex)
{
ex.printStackTrace();
}
Every Java developer should be able to spot at least two. If you can't spot all five, then read on – there is
something in here for you.
すべての Java developer は、少なくとも二つは指摘できるべきでしょう。もし五つすべてを指摘できないなら、この記
事の続きを読んでください。あなたのためものがあります。
Rather than generalities and pontifications, we decided to use what we call anti-patterns : (unfortunately)
common bad programming practices that we have seen time and again in Java code. Our purpose is to familiarize
you with these counter-examples so that you can quickly spot them, and avoid or remediate them.
わたしたちは generalities や pontifications をするのではなく、わたしたちがアンチパターンと呼ぶ、Java code で
よく見かける (残念なことに) 一般的な bad programming practices を使うことにしました。わたしたちの目的はこのよ
うな counter-examples にあなたを familiarize させることであなたがそういったものを即座に指摘できるようにし排除
したり正したりできるようにするというものです。
And now for our hall of shame – the six most common misuses and abuses of exception handling.
exception handling について
最も一般的な六つの misuses と abuses
Anti-pattern #1 : try-catch-bury
アンチパターン 1 :
catch(Exception ex) {
ex.printStackTrace();
This is the bane of Java programming – catching an exception and not doing anything about it. In terms of
frequency and severity, this is probably comparable to the infamous unchecked buffer problem in C and C++. If
you see this anti-pattern, you can be 99% sure that it is wrong (there are a few cases where it might make
sense, but they should be carefully commented to make it clear to the maintenance developer).
これは the bane of Java programming (Java プログラミングの破滅?) です。例外を捕捉するけれどもそれに対する
処理を一切行わない。頻度と重大度から言うとこれは、C や C++ において悪名高いチェックなしバッファー問題
(unchecked buffer problem) に匹敵するものでしょう。もしあなたがこのアンチパターンを見たのなら、99% それが
間違いであると確信できるでしょう (このようにすることに意味があるケースが、数は少ないものの存在しています。
しかしその場合でも maintenace developer に対してその意図を明確にするために注意深くコメントを残しておくべ
きです)。
This is wrong because an exception (almost) always means that something bad (or at least unexpected) has
happened. Yet we choose to ignore and silence that cry for help. Calling printStackTrace does not qualify as
“handling an exception” – it’s OK for debugging but should not be present past that initial step.
これが間違いなのは、例外というのものは (ほぼ) 常に何かがおかしい (少なくとも期待したものではない) ことが起き
たことを意味しているからです。わたしたちはそれでも例外を無視することを選択し、cry for help を黙殺しました。
printStackTrace の呼び出しは “handling an exception”として qualify されません。
デバッグのために printStackTrace を使うことはかまいませんが、present past that initial step すべきではありま
せん。
This problem is frighteningly pervasive. If you look at the documentation for the JDK class ThreadDeath, you
will see the following comment : "The class ThreadDeath is specifically a subclass of Error rather than
Exception, even though it is a "normal occurrence", because many applications catch all occurrences
of Exception and then discard the exception." This means that this poor programming practice is so common
that, in an unhealthy feedback loop, it has affected the design of Java itself. Grunt.
この問題は frighteningly pervasive です。JDK の class ThreadDeath のドキュメントを見ると次のようなコメントが
あります。"The class ThreadDeath is specifically a subclass of Error rather than Exception, even though it
is a " normal occurrence", because many applications catch all occurrences of Exception and then
discard the exception." (ThreadDeath クラスは、それが "normal occurence" であっても specifically には
Exception のサブクラスではなく Error のサブクラスとなっています。それは多くのアプリケーションで、発生した例外
すべてを捕捉してもその例外を捨ててしまっているからです) このことはこの poor programming practice が Java 自身
の設計に影響されていて unhealthy な feedback loop の中であまりにも一般的 (so common) であることを意味していま
す。
What should you do instead ? You basically have four options :
代わりにすべきことは何でしょうか? 基本的には四つの選択肢があります。
1. Handle the exception : do something about it. Correct the problem, notify someone or something, whatever
makes sense in this particular situation. Once again, calling printStackTrace does not qualify as
“handling the exception”.
その例外を処理する: 例外に関する何かを行います。問題を修正する。誰か(もしくなにか) に notify する。特定の
シチュエーションで意味のあることを行う、もう一度繰り返しますが、printStackTrace の呼び出しは“handling
the exception”として qualify しません。
2. Re-throw the exception. This is not uncommon if your exception handling code examines the exception for
additional information, and decides that it cannot handle it after all.
その例外を再送出する: あなたの例外処理コードが additional information のためにその例外の検査をしていて、
その結果その例外を handle できないと判断したのであればそれは uncommon ではありません。
3. Translate the exception into another exception. Most often this is used to translate a low-level
exception into an application-level exception.
その例外を別の例外に translate する: ほとんどの場合これは low-level な例外を application-level の例外へ
translate するのに使われます。
4. Don't catch the exception – if you're not going to do anything about it, why bother catching it? Let it
go (and, if necessary, declare it in the signature of your method).
例外を捕捉しない: もしなにもするつもりがないのならなぜその例外を捕捉したのでしょうか?
Let it go (and, if necessary, declare it in the signature of your method).
なすがままに (そしてもし必要なら、捕捉する例外をメソッドのsignatrue で宣言する)
Solution 1 : if you catch an exception, do something about it. Do not bury it.
解決策1: 例外を捕捉したら、それに対する何らかの処理を行うこと。握りつぶしてはいけません。
Anti-pattern #2 : Pokémon® – Gotta catch’em all
アンチパターンその2:
catch(Exception ex)
It is often tempting to have a very general catch statement. The most common is undoubtedly catch(Exception ex).
In almost all cases, that is a bad idea. Why?
very general な catch statement を頻繁に作ろうとしてしまうこと。最も一般的なのはまず間違いなく
catch(Exception ex) ですが、ほとんど全てのケースでこれは bad idea です。なぜでしょうか?
To understand why, we need to step back and consider the purpose of a catch statement. You use a catch
statement to indicate that you anticipate certain exceptions, and that you are willing to handle them. The
class of the exception(s) is how you tell the Java compiler which exceptions you want to handle. Since the
vast majority of exceptions inherit directly or indirectly from java.lang.Exception, specifying that in your
catch statement effectively says that you want to handle almost any exception.
それがなぜなのかを理解するには、 step back して catch 文の目的を考察する必要があります。catch 文は特定の
exceptions を anticipate しているのを indicate して、それを handle する意志があるということを示すために使いま
す。例外のクラスは、あなたが handle したいと望んでいる例外をJava コンパイラーに指示するものです。例外の vast
majority は直接間接に java.langa.Exception を継承したものですから、あなたがcatch 文で specifying したのはあな
たがほぼすべての例外 (almost any exception) を handle したいということだと効果的に述べています。
Let's look at the code sample again. What kind of exceptions are we likely to catch － The most obvious one
is of course SQLException, quite likely to happen any time you deal with JDBC. IOException is another
possibility – we are dealing with a stream writer. You can already see the problem : it does not make sense to
handle these two (very different) types of error in the same catch block. It would make a lot more sense to
have two catch blocks, one for SQLException, one for IOException.
ではもう一度サンプルコードを見てみましょう。例外の種類はわたしたちが catch しようとしているものです。もっとも
明白なのはもちろん SQLException で、これは JDBC を扱うときにはいつでも発生しうるものです。IOException はもう
ひとつの候補ですが、ここでは stream writer を取りあげましょう。あなたはすでに問題を理解しています。これら二つ
の (非常に異なった) 型のエラーをひとつの catch block で handle することには意味がありません。SQLExcetption の
ためのものと IOExceptiono のためのものの二つの catch ブロックを持つことのほうがずっと意味のあるやり方です。
In addition, there is a large number of other exceptions that could occur. What if, for some obscure reason,
executeQuery returns null ― You'll get a NullPointerException in the next line, yet that (unexpected)
exception will be ignored (unless you happen to be looking at the console for your program – and even then,
unless you wrote that code yourself, what good does that do you ?).
加えて、発生する可能性のある数多くの other exceptions があります。いくつかの奇妙な理由によって executeQuery が
null を返したとすると、次の行で NullPointerException が発生します。そしてこれはこれは無視することのできない(し
かも予期していなかった)例外です。
(unless you happen to be looking at the console for your program
– and even then, unless you wrote that code yourself, what good does that do you ?).
The better approach is to be more specific. In this case, we should have two catch blocks, one for
SQLException, the other for IOException. For one thing, this makes it clear to the next reader of this code
that you have thought about these scenarios. But what about all the other exceptions, you ask － Let them go.
Do not handle them (unless you have a reason to). You cannot (and in fact should not) try to handle all
possible exceptions – let them bubble up, someone else will deal with them (the JVM if no one else).
もっと良いアプローチはより specific にすることです。このケースでは、SQLException のためのものとそのほかの
IOException のためのものという、ふたつの catch ブロックを持つべきなのです。
For one thing,
これはそのコードの次の読者のために、あなたがそのコードでthese secanios で考えていたことを明確にします
しかしそのほかすべての例外に対しては (理由がない限りは) それらを handle してはいけません。放置しましょう。
あなたは可能性のある例外をすべて handle することを試みることはできません(し、すべきではありません)。
– let them bubble up, someone else will deal with them (the JVM if no one else).
There are some instances where catching Exception is a good idea especially when doing testing or debugging.
Once you have isolated the cause of the problem you need to remove the catch Exception and replace it with the
appropriate kind of Exception(s).
とくにテストやデバッグをしているときには、例外の catch が good idea であるようないくつかのインスタンスが存在
しています。問題の原因を insolate できたら、その catch Exception を取り除いて適切な種類の例外で置き換える必
要があります。
Solution 2 : Be as specific as possible in your catch statements, and use multiple catch statements if
necessary. Do not try to handle all possible exceptions.
解決策その2
自分の catch statemens は可能な限り specific にする。そして必要であれば multiple catch statements を使う。
可能性のある例外すべてを handle しようとはしない。
Anti-pattern #3 : The forgotten bathroom key
アンチパターンその3
try {
Statement stat = conn.createStatement();
ResultSet rs = stat.executeQuery("select uid, name from user");
while (rs.next())
{
out.println("User ID : " + rs.getString("uid") +
", name : " + rs.getString("name"));
}
conn.close();
One of us used to work in a small office with only one bathroom. To go there, you had to use a key, which was
hung on a nail. One programmer was notorious for often neglecting to return the key to its rightful place,
thereby inconveniencing the rest of the office. Often, this was because he would get interrupted while coming
back to his desk, and he would forget to return the valuable resource to its place.
わたしたちの一人は bathroom が一つしかない small office で働いていました。そこへ行くためには爪の大きさほどの
鍵を使わなければなりませんでした (違うか)。
あるプログラマーはこの鍵を正しい場所に戻すのをしばしば忘れてしまっていて、そのせいで
オフィスの他の人たちに不便を強いていました。
彼は自分の机に戻っている最中にも割り込みを受けることがあり、正しい場所にこの valuable resource を戻すことを忘
れてしまうのでそのような事態が頻繁に起きていました。
Similarly, when an exception occurs, it affects the execution path of your program. It is easy to verlook that
simple fact. If you use resources such as files, sockets, JDBC connections, etc…, you need to make sure that
they are properly closed and released even if an exception occurs. Java has a mechanism designed just for such
a thing : finally.
これと同様に、例外は発生したときにあなたのプログラムの実行パスに影響を及ぼします。そんな単純な事実を overlook
してしまうのは容易なことです。ファイル、ソケット、JDBC connections, etc…, のようなリソースを使ったのなら、例
外が発生した場合であってもそれらを確実にクローズしたりリリースしなければなりません。Java にはそのために設計さ
れた仕組みがあります。それが finallyです。
Finally is a wonderful thing : it allows you to guarantee that your cleanup code will be executed before the
end of the try/catch/finally block, regardless of whether an exception is being thrown or not. Think of it as a
knot on your finger, which will remind you to return the bathroom key, even if something distracts you. And yet,
finally is rarely used, even by intermediate programmers.
finally は wonderful thing です。例外が throwされたかどうかには関係なく、try/catch/finally ブロックの終端の直前
で claenup code が実行されるのを保証するのを可能にします。
あなたが何かに気をとられてしまっていても bathroom の鍵を返すのを思い出させる指先の結び目を考えてみてください。
And yet, intermediate programmers によってさえ finally はめったに使われません。
Of course, finally blocks should be written with great care. In particular, you should be careful about
exceptions being thrown in a finally block – this is your final chance to clean things up, don’t let it slip.
In some cases, it may be acceptable to bury an exception that is thrown in a finally block. Think of it as a
best effort. Regardless, use your best judgment, or better yet, ask someone more experienced.
もちろん finally ブロックは大いに注意を払って記述されるべきものです。とくに、finally block で throw される
exception については注意深くあるべきです。
そのような場面はなにかを片付ける最後のチャンスなのですから don't let it slip。
一部のケースでは finally block で throw される exception は bury してしまうのが acceptable かもしれません。
これは best effort とみなされます。
あなたが best judgment しているか better yet なのかには関係なく、もっと経験をつんでいる人に尋ねてみましょう。
Solution 3 : Make sure that all resources are properly released. Use finally liberally.
解決策その3 すべてのリソースを確実に適切に解放する。finally を liberally に使う。
Anti-pattern #4 : If you don't know why I am mad, I won't tell you
アンチパターンその4
try {
Statement stat = conn.createStatement();
ResultSet rs = stat.executeQuery(
"select uid, name from user");
while (rs.next())
{
out.println("User ID : " + rs.getString("uid") +
", name : " + rs.getString("name"));
}
conn.close();
out.close();
}
catch(Exception ex) {
ex.printStackTrace();
Look at the code again : what happens if an exception occurs during the execution of the loop ― Will we get
information which can tell us what causes the loop to fail? Not really. All we will get is an indicator of
something wrong in the area of the class that is doing the processing, but may not get any input as to what
caused the problem within this loop.
コードをもう一度良く見てください。ループを実行中に例外が発生したときになにが起きているでしょうか? ループを失
敗させた原因を区別できるような情報を得られるでしょうか? Not really. わたしたちが手に入れられるものは、処理を
行っていたクラスの領域で何か間違ったことが起きたという indicator がすべてです。そして、ループの中で問題を引
き起こした原因となった入力については一切手に入れられません。
The basic “Stack trace” which shows the path of execution to the class that caused the exception is cryptic,
and not easily parsed. It also causes any tester without a Java development background to report application
problems with a very general description such as “encountered an ugly Java problem”. If such an exception is
wrapped to display a more user-friendly message they are more likely to repeat the specific message displayed
to them. Not everyone who tests business applications is experienced in the delicate art of stack trace
interpretation.
exception を引き起こしたクラスの実行パスを show した基本的な“Stack trace”は cryptic で、解析も容易ではありま
せん。Java の development の background を持たない tester すべてに、アプリケーションの問題で
“encountered an ugly Java problem” のような very general な report をさせてしまいます。
もしそういった例外が more user-friendly なメッセージで wrap されていれば、
tester たちは表示された specific message を repeat するでしょう。
ビジネスアプリケーションのテストをする人が皆、stack trace の解釈 interpretation という delicate art の
経験豊富というわけではないのです。
In addition to displaying a more user friendly message, there is great benefit in providing a little extra
data such as the Class, Method, and a text message. While it is true this information can be obtained from
the stack trace, it is much easier to read when it is isolated. Also, taking the extra time to describe the
behavior when you are creating the code will greatly expedite resolving the problem later.
よりユーザーフレンドリーなメッセージを表示することに加えて、クラスやメソッド、テキストメッセージのような
little extra data を provide することには大きな利益があります。
そういった情報がスタックトレースから得られはしますが、isolate されたことでより読みやすいものになるのです。
あなたがコードを書くときに behavior を describe するのに余計な時間をかけることで、
あとで問題を解決するときに greatly expedite するのです。
One solution is to embed a snippet like the one below wherever exceptions get logged in the application.
You can use the this.getClass().getName() method, and to insert the method named and a text message
everytime the program reports a checked exception. This practice makes exceptions easy to read and
easy to parse.
解決策の一つは、例外が発生したときにアプリケーションのどこで起きたのかを記録する snipet を埋め込むというものです。
プログラムがchecked exception を report する度にメソッド名とテキストメッセージを埋め込むのに
this.getClass().getName() method が使えます。この practice は例外処理を読んだり解析するのを簡単にします。
this.getClass().getName(), “mymethod”, “some message”
One caveat to this approach is that with a static method call you need to manually need to insert the class
name because the “this” object reference does not have a this to refer to. Simply replace the
this.getClass().getName() with your class name “myClass”.
このアプローチの one caveat は static method call を伴う場合にはクラス名を自分で挿入する必要があることです。
それは、"this" オブジェクトの reference がオブジェクトへの参照である this を持っていないためです。
this.getClass().getName() を単純に自分のクラス名“myClass”で置き換えます。
Solution 4 : report a reasonable amount of data in a way that is easy to read
解決策その4 読みやすい方法で適切な量のデータをレポートする
Anti-pattern #5 : overzealous try
アンチパターンその5 熱心すぎる try
try {
Statement stat = conn.createStatement();
ResultSet rs = stat.executeQuery(
"select uid, name from user");
while (rs.next())
{
out.println("User ID : " + rs.getString("uid") +
", name : " + rs.getString("name"));
}
conn.close();
out.close();
Putting too much activity in a single try block is a bad programming practice, even though it is common. The
reason it is a common practice is that it takes extra time to isolate what in a particular block could go
wrong and what exceptions could get created as a result of this processing. Wrapping too many statements in a
giant catch is like packing your household goods for a move using refrigerator-sized boxes. Sure, all your
goods are in one place but imagine the sorting task you will have in the near future. For the inexperienced
developer it is easier to put a bunch of statements in a try block, and wrap it all up in a generic catch
Exception than to isolate the statements. This practice makes troubleshooting Exceptions that get generated
during program execution that much more difficult because there are more variations to check to find out
what caused the Exception.
ひとつの try ブロックに多すぎる activity を押し込めることは、それが一般的に行われていることであっても bad な
プログラミング practice です。これが一般的な practice である理由は、go wrong する可能性のある特定のブロックと
その処理の結果として生成される可能性がある例外とを isolate するのには extra time を take するためです。多すぎ
る statements を巨大な catch で wrapすることは、引っ越しするのに冷蔵庫大の箱を使って household goods をパッキ
ングすることに似ています。確かにあなたの goods はすべて一つの場所にありますが、近い将来に行うことになるであろ
う sorting task を想像してみてください。あまり経験をつんでいない developer のために、try block に bunch of
statements を put してそれをまるごと isolate the statements するよりも generic catch Exception で wrapする
方がより簡単になっています。この practice は、ずっと困難なプログラム実行中に生成された Exception を解決します。
それはその Exception を引き起こしたのが何かを見つけ出すための検査にはもっと多くの variations があるからです。
For lack of space, the code example does not really illustrate this fully, but this is a common problem.
スペースが足りないので例に挙げたコードはこのことを完全には表現していませんが、これは一般的な問題です。
Solution 5 : keep try blocks as small as possible, but no smaller
解決策その5 try ブロックを可能な限り小さく、ただし小さすぎないようにする。
Anti-pattern #6 : incomplete execution
アンチパターンその6
不完全な実行
while (rs.next())
{
out.println("User ID : " + rs.getString("uid") +
", name : " + rs.getString("name"));
}
This is the silent killer of Java systems. Look at the code again, and imagine what happens if an exception
is thrown in the middle of the loop. The execution of the loop will be interrupted, the catch block will be
executed, and that's about it. But what about the data that we are writing out? It will be silently incomplete.
Whoever or whatever is supposed to use this data will receive incomplete (and hence incorrect) data, but will
probably have no idea that it is incomplete. For some systems, that is a problem far more serious than any
crash.
これは Java システムの silent killer です。コードをもう一度よーく見て、そしてループの途中で例外が送出されたと
きに何が起きるのかを想像してください。その例外は interrupt され、例外に対応する catch ブロックが実行されます。
しかし、わたしたちが書き出したデータはどうなるでしょうか? それは silently に incomplete なものになってしまう
でしょう。このデータを誰が使うと仮定したとしても incomplete な (したがって incorrect な) データを受けとるで
しょうが、それが不完全なものであるかどうかはおそらくわかりません。一部のシステムではこれはクラッシュするより
ももっと深刻な問題となります
A better approach here would be to attempt to write a message to the output, signaling that the data could not
be completely written. Another possibility would be to buffer the output (if possible) and write it out only
once we have it all ready to go.
ここでのより良いアプローチは、メッセージを出力に書き出すことを attempt してデータが完全には書き出せなかったこ
とを signaling することでしょう。もうひとつの possibility は、(可能であれば)出力をバッファリングしてすべての
準備が完了したときにそれを一度だけ書き出すというものです。
Solution 6 : consider all likely exceptions and how they will affect the flow of execution
解決策その6 すべての likely exceptions を考慮し、それがどのように実行の流れに影響するかを考えてください。
Example (re-written)
書き直した例
Given these facts, let's see now how the same code would look like. Note that it is quite a bit more verbose.
That is not a bad thing – good code always includes a lot of error handling.
以上のことを踏まえて、コードがどのようになるのか見てみましょう。
it is quite a bit more verbose であることに注意してください。
それは悪いことではありません。優れたコードは常に多くのエラーハンドリングを含んでいるのです。
OutputStreamWriter out = ...
java.sql.Connection conn = ...
try {
Statement stat = conn.createStatement();
ResultSet rs = stat.executeQuery(
"select uid, name from user");
while (rs.next())
{
out.println("User ID : " + rs.getString("uid") +
", name : " + rs.getString("name"));
}
}
catch(SQLException sqlex)
{
out.println("Warning : data incomplete due to exception");
throw new ApplicationException(
"SQL error while reading", sqlex);
}
catch(IOException ioex)
{
throw new ApplicationException(
"I/O error while writing", ioex);
}
finally
{
if (conn != null)
try {
conn.close();
}
catch(SQLException sqlex2)
{
System.err(this.getClass().getName() +
".mymethod - cannot close JDBC connection : " +
sqlex.toString());
}
if (out != null)
try {
out.close();
}
catch(IOException ioex2)
{
System.err(this.getClass().getName() +
".mymethod - cannot close outfile" +
ioex2.toString());
}
}
Conclusion 結論
All the anti-patterns in this article were inspired by actual code, written by professional programmers.
Before you snicker, ask yourself whether your code is really free from these poor practices. Even the most
experienced programmers sometimes fall back into them, simply because they are easy (we certainly do). Think
of them as bad habits – they are notoriously difficult to shake off, but just trying makes you a better person.
本 article で取りあげたアンチパターンはすべて、プロのプログラマーが書いた実際のコードに inspire されたものです。
Before you snicker、 自分のコードが本当にこれら poor practices のようなものではないか自身に問うてみてく
ださい。経験豊富なプログラマーの大部分でさえ fall back into them してしまうことがありますが、なぜならそれは、
アンチパターンとはそうなりがちなもの (やってしまいがちなもの) であるからです。そういった習慣は、悪い習慣 (bad
habits) だと考えてください。それは shake off するのが notoriously difficult なものでありますが、
(shake off に) try するだけでもあなたを better person にするでしょう。
Of course, nothing in this article should be taken as gospel. Use your common sense and your experience. For
each anti-pattern described here, you could certainly come up with counter-examples. As long as the rules are
broken willingly and thoughtfully, you have ourblessing, but we do beg for one favor : if what you do is not
obvious, please write a nice comment. You'll thank yourself later. Also, share the your wealth of knowledge
with others on your team; extra time spent on training is a small price to pay in comparison to a massive
refactoring effort at the end of the development cycle.
もちろんこの article には gospel として受け取るべきものはありません。あなたの常識 common sense と経験 experience
を使ってください。ここで説明したアンチパターンのそれぞれについて、counter-example をいくつか提示できるでしょう。
ルールが willingly かつ thoughtfully に破られている限りは
あなたには our blessing がありますが、わたしたちは one favor を求めます。
もしあなたのしていることが明確でないのなら、どうか nice なコメントを書いてください。
あとで自分自身に感謝することになるでしょう。
また、the your wealth of knowledge をあなたのいるチームの他のメンバーと共有してください。
トレーニングのために必要な extra time は
a massive refactoring effort at the end of the development cycle
に必要な費用と比較すれば小さなものです。
References 参照
Practical Java: Programming Language Guide – Peter Haggar - ISBN: 0201616467. An invaluable resource, a must-read for any Java programmer.
The Elements of Java Style - Scott W. Ambler Alan Vermeulen Greg Bumgardner - ISBN: 0521777682. A collection of good coding practices, all neatly grouped in a small booklet. You may not agree with it all, but if you have a team, you need to either adopt this book, or write your own. Adopting this one (perhaps with amendments) is a lot easier.
The Sun Java online tutorial : http://java.sun.com/docs/books/tutorial/essential/exceptions Does a good job of introducing the basic concepts, but does not go beyond that.
Effective Java: Programming Language Guide – Josh Bloch - ISBN: 020131005-8. Another excellent reference that is easy to read.
About the authors
著者について
We'd love to hear from you ! Please don't hesitate to send your comments, suggestions
and criticisms to either of us.
Craig Dewalt is a surfer who likes to lead Java development teams. He can be reached
at goflyr@yahoo.com. Max Tardiveau is a solution architect for Versata. He can be
reached at max@tardiveau.com.
の話。
Book Review and Interview: Real World OCaml
![機動戦士ガンダム0083 -ジオンの残光- [Blu-ray]](http://ecx.images-amazon.com/images/I/51Pmln00h9L._SL160_.jpg)
![機動戦士ガンダム 逆襲のシャア [Blu-ray]](http://ecx.images-amazon.com/images/I/51mKXwBcckL._SL160_.jpg)
