TOP
＞
設計・移行・活用
＞ Error、Throwableクラスを継承しない（C_EXT004）
Javaコーディング規約
第１１回：コレクション・ストリーム・例外に関するコーディング規約
著者：
電通国際情報サービス
高安 厚思、東田 健宏、玉村 雅也
2006/1/12
前のページ
1
2
3
4
Error、Throwableクラスを継承しない（C_EXT004）
ErrorクラスやThrowableクラスは継承しないでください。
Errorクラスは、プログラムでキャッチしても対処できない重大な問題をあらわしており、Errorクラスを継承すべきではありません。またThrowableクラスは、Exceptionクラス／Errorクラスのスーパークラスですので、このクラスを継承するとエラーと例外の意味が曖昧になってしまいます。
プログラムで例外サブクラスを定義する際は、Errorクラス／Throwableクラスではなく、Exceptionクラスを継承して定義するようにしましょう。
例外クラスは無駄に定義しない（C_EXT005）
例外クラスは無駄に定義せずに、できる限りJDK標準パッケージに含まれる例外を利用しましょう。何も考えずに自作の例外クラスを作ると、バグ内包の危険性や不必要なテストを増やすことにつながります。
新たに例外を定義する場合は、特定のメソッドだけで利用される例外を定義するのではなく、例外の必要性を考慮および検討した上で、アプリケーション全体で利用できるよう汎用的に定義するようにしましょう。
もしフレームワークや製品パッケージを利用して開発している場合は、そこで用意されている例外クラスを使用するか、そのサブクラスを定義して使用するのが一般的です。
finallyブロックは必ず実行される（C_EXT006）
tryブロックの中で例外がキャッチされずにreturnしても、必ずfinallyブロックは実行されます。
よってfinallyブロックには、例外がキャッチされてもされなくても必ず行うべき処理を記述することが重要です。
finallyブロックは必ず実行されるため、メソッドの返り値に影響がある記述やreturn文を記述してしまうと、想定外の動作をする可能性があります。finallyブロックには、ストリームのクローズ処理など、必ず実行されるべき処理を実装するようにしましょう。
まとめ
今回は、コーディング規約のコレクション／ストリーム／例外を紹介してきました。
これらの規約を守ることにより表5にあげるような効果が見込めることを理解していただけたかと思います。
Java2以降のコレクションフレームワークによるパフォーマンス向上、バグの削減
ストリーム利用時のメモリリークの防止
適切な例外処理による保守性の向上
表5：規約を守ることによって見込める効果
表5すべての効果を満たすには、実装経験、さらなるJava言語知識が必要ですが、これらの効果がすべて現れるようなソースコードが書けるようになると、プログラムの品質向上へつながります。
今回紹介した規約を守ることで、品質の高いプログラムへつながるJavaプログラミングをぜひ目指してください。
前のページ
1
2
3
4
著者プロフィール
株式会社電通国際情報サービス 高安 厚思
株式会社電通国際情報サービス 開発技術センター
Java（J2EE）／オブジェクト指向の研究開発やプロジェクト支援、開発コンサルティングに従事。モデル、アーキテクチャ、プロセスが探求対象。今回は Javaコーディング規約2004の仕掛け人。
著者プロフィール
株式会社電通国際情報サービス 東田 健宏
株式会社電通国際情報サービス 開発技術センター
CTI、Webアプリの開発経験を経て、現在は主にプロジェクトマネジメント支援、プロセスエンジニアリング、ソフトウェア工学研究開発に従事。最近はコーチング、ファシリテーションといったヒューマン系スキルに興味を持ち日々修得に努めている。
著者プロフィール
株式会社電通国際情報サービス 玉村 雅也
株式会社電通国際情報サービス アウトソーシング事業部
Securityに関わる研究開発やプロジェクト支援の経験を経て、現在は大手企業の管理会計システムのBPRプロジェクトに従事。最近は難敵ABAPと戦いながら、日々を送っている。
INDEX
第11回：コレクション・ストリーム・例外に関するコーディング規約
はじめに
ストリーム
例外
Error、Throwableクラスを継承しない（C_EXT004）
