Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
Effective Java 輪読会 第8回
(項目63~65)
2014/2/26
開発部 野口
項目63
詳細メッセージにエラー記録情報を含め
る
例外の文字列表現は、
後の分析のためにエラーを記録す
る
 プログラムがキャッチされなかった例外によ
り失敗した場合は、システムは自動的にその
例外のスタックトレースを表示する
 スタックトレースには、その例外の toString メ
ソッ...
すべてのパラメータと
フィールドの値を含める
 たとえば、IndexOutOfBoundsException には、下
記をすべて含める
 下限範囲
 上限範囲
 範囲内に収まらなかった実際のインデックス
不要なものは含めなくてよい
 スタックトレースは、ソースファイルと一緒
に分析されるもの
 例外のスロー箇所およびスタック上のすべてのメ
ソッド呼び出しのファイルと行番号が含まれる
 よって、長ったらしい説明は不要
例外の文字列表現と
ユーザレベルのエラーメッセージ
 ユーザレベルのエラーメッセージ
 エンドユーザに対してわかりやすくなければならない
 例外の文字列表現
 エラーを解析する際にプログラマやフィールドサービ
ス担当者が主に使用するため...
例外のコンストラクタを工夫する
(1)
 IndexOutOfBoundsException は、このようなコンストラクタを持って
いればよかったのに……。
public IndexOutOfBoundsException(int lower...
例外のコンストラクタを工夫する
(2)
 エラー記録情報にアクセッサ-を提供する
 チェックされる例外は、特に
 エラーから回復するのに役立つ可能性がある
 参照)項目58 回復可能な状態にはチェックされる例
外を、プログラミングエラー...
項目64 エラーアトミック性に努める
エラーアトミック性
 失敗したメソッド呼び出しは、オブジェクト
をそのメソッド呼び出しの前の状態にしてお
く
 このような性質を持つメソッドは、エラーアト
ミックであると呼ばれる
 特にチェックされる例外については重要(再び項
目58)
エラーアトミック性を達成する
方法
 不変オブジェクトを用いる
 操作を行う前にパラメータの正当性を検査す
る
 エラーを捕捉し、回復するコードを書く
 Copy and Swap イディオムを用いる
不変オブジェクトを用いる
 オブジェクトが不変ならば、エラーアトミッ
ク性はコストがかからない
 参照)項目15 可変性を最小限にする
操作を行う前に
パラメータの正当性を検査する
 あるいは、失敗するかもしれない部分が、オブジェクトを変
更する部分よりも前に行われるようにする
 例)TreeMap では、要素の追加前に検索を行い、その時点で
ClassCastExcept...
エラーを捕捉し、
回復するコードを書く
 主に永続的な(ディスクに基づく)データ構
造に対して使用されている
 あまり一般的でない方法
 (Java の例外に対処する方法としては、という意
味だと思います)
Copy and Swap イディオムを用い
る
 オブジェクトの一時的コピーに対して操作を
行い、操作が完了したらオブジェクトの内容
を一時的コピーの内容で置き換える
 例)Collection.sort
達成可能ではない場合・
望ましくない場合
 たとえば ConcurrentModificationException が発生
したとき、回復は難しい
 既にオブジェクトの整合性が保たれていない可能
性が高い
 エラーは、例外とは反対に、一...
まとめ
 メソッドの仕様の一部である例外は、オブ
ジェクトをメソッド呼び出しの前と同じ状態
にすべき
 そうでない場合、API ドキュメンテーションは
オブジェクトがどのような状態に置かれるの
かを明確に示すべき
See also:
 『Exceptional C++』(Herb Sutter)
 「例外安全」を掘り下げた名著
 ただし、ピアソン桐原の技術書からの撤退により、
日本語版は目下のところ絶版です……。
 丸善の活躍に期待!(のぞみうす)
項目65 例外を無視しない
例外を無視しないようにしよう
 火災警報を無視して警報を切ってしまうのと同
じ!
 やばすぎ
 例外は目覚まし時計じゃない
 最低でも、なぜ無視するのが適切なのかコメントすべ
き
try {
...
} catch (SomeExcep...
例外を無視するのが
適切かもしれない状況の例
 FileInputStream をクローズするとき
 ファイルの状態を変更していなければ、別に回復
する必要もない
 既に情報を読み出しているなら、あえて中断する
必要もない
 ただし、記...
適用範囲
 チェックされる例外
 回復できるはず、回復が期待されている
 回復しましょう
 チェックされない例外
 回復できなければ、せめて外側に伝播させて、速
やかに失敗させる
 問題の発生箇所と発見箇所は近ければ近いほどよいの
...
Prochain SlideShare
Chargement dans…5
×

Effective Java 輪読会 項目63-65

1 091 vues

Publié le

Publié dans : Technologie
  • Identifiez-vous pour voir les commentaires

  • Soyez le premier à aimer ceci

Effective Java 輪読会 項目63-65

  1. 1. Effective Java 輪読会 第8回 (項目63~65) 2014/2/26 開発部 野口
  2. 2. 項目63 詳細メッセージにエラー記録情報を含め る
  3. 3. 例外の文字列表現は、 後の分析のためにエラーを記録す る  プログラムがキャッチされなかった例外によ り失敗した場合は、システムは自動的にその 例外のスタックトレースを表示する  スタックトレースには、その例外の toString メ ソッドの結果である例外の文字列表現が含ま れる
  4. 4. すべてのパラメータと フィールドの値を含める  たとえば、IndexOutOfBoundsException には、下 記をすべて含める  下限範囲  上限範囲  範囲内に収まらなかった実際のインデックス
  5. 5. 不要なものは含めなくてよい  スタックトレースは、ソースファイルと一緒 に分析されるもの  例外のスロー箇所およびスタック上のすべてのメ ソッド呼び出しのファイルと行番号が含まれる  よって、長ったらしい説明は不要
  6. 6. 例外の文字列表現と ユーザレベルのエラーメッセージ  ユーザレベルのエラーメッセージ  エンドユーザに対してわかりやすくなければならない  例外の文字列表現  エラーを解析する際にプログラマやフィールドサービ ス担当者が主に使用するためのもの  アプレッソにおいては、開発者、サポートセンター、リセ ラーの担当者の方……。  疑問:特に DataSpider Servista では、製品の性質上(あるい は、現状の課題として?)、エンドユーザが例外を目にし て自身で対処することも多いので、例外の文字列をわかり やすくすることに意義がある?  できるだけエラーコードを出すようにしてます
  7. 7. 例外のコンストラクタを工夫する (1)  IndexOutOfBoundsException は、このようなコンストラクタを持って いればよかったのに……。 public IndexOutOfBoundsException(int lowerBound, int upperBound, int index) { // エラーを記録する詳細メッセージを生成する super( "Lower bound: " + lowerBound + ", Upper bound: " + upperBound + ", Index: " + index); // プログラミングによるアクセスのためにエラー情報を保存する this.lowerBound = lowerBound; this.upperBound = upperBound; this.index = index; }
  8. 8. 例外のコンストラクタを工夫する (2)  エラー記録情報にアクセッサ-を提供する  チェックされる例外は、特に  エラーから回復するのに役立つ可能性がある  参照)項目58 回復可能な状態にはチェックされる例 外を、プログラミングエラーには実行時例外を使用す る  チェックされない例外も、あった方がよい  参照)項目10 toString を常にオーバーライドする
  9. 9. 項目64 エラーアトミック性に努める
  10. 10. エラーアトミック性  失敗したメソッド呼び出しは、オブジェクト をそのメソッド呼び出しの前の状態にしてお く  このような性質を持つメソッドは、エラーアト ミックであると呼ばれる  特にチェックされる例外については重要(再び項 目58)
  11. 11. エラーアトミック性を達成する 方法  不変オブジェクトを用いる  操作を行う前にパラメータの正当性を検査す る  エラーを捕捉し、回復するコードを書く  Copy and Swap イディオムを用いる
  12. 12. 不変オブジェクトを用いる  オブジェクトが不変ならば、エラーアトミッ ク性はコストがかからない  参照)項目15 可変性を最小限にする
  13. 13. 操作を行う前に パラメータの正当性を検査する  あるいは、失敗するかもしれない部分が、オブジェクトを変 更する部分よりも前に行われるようにする  例)TreeMap では、要素の追加前に検索を行い、その時点で ClassCastException で失敗する(エラーアトミック性は保たれる) public Object pop() { if (size == 0) throw new EmptyStackException(); Object result = elements[--size]; elements[size] = null; // もし検査がなければ、 // ArrayIndexOutOfBoundsException が 潜在! return result; }
  14. 14. エラーを捕捉し、 回復するコードを書く  主に永続的な(ディスクに基づく)データ構 造に対して使用されている  あまり一般的でない方法  (Java の例外に対処する方法としては、という意 味だと思います)
  15. 15. Copy and Swap イディオムを用い る  オブジェクトの一時的コピーに対して操作を 行い、操作が完了したらオブジェクトの内容 を一時的コピーの内容で置き換える  例)Collection.sort
  16. 16. 達成可能ではない場合・ 望ましくない場合  たとえば ConcurrentModificationException が発生 したとき、回復は難しい  既にオブジェクトの整合性が保たれていない可能 性が高い  エラーは、例外とは反対に、一般には回復不 可能  著しくコストや複雑さが増すとき、望ましく ないかもしれない
  17. 17. まとめ  メソッドの仕様の一部である例外は、オブ ジェクトをメソッド呼び出しの前と同じ状態 にすべき  そうでない場合、API ドキュメンテーションは オブジェクトがどのような状態に置かれるの かを明確に示すべき
  18. 18. See also:  『Exceptional C++』(Herb Sutter)  「例外安全」を掘り下げた名著  ただし、ピアソン桐原の技術書からの撤退により、 日本語版は目下のところ絶版です……。  丸善の活躍に期待!(のぞみうす)
  19. 19. 項目65 例外を無視しない
  20. 20. 例外を無視しないようにしよう  火災警報を無視して警報を切ってしまうのと同 じ!  やばすぎ  例外は目覚まし時計じゃない  最低でも、なぜ無視するのが適切なのかコメントすべ き try { ... } catch (SomeException e) { }
  21. 21. 例外を無視するのが 適切かもしれない状況の例  FileInputStream をクローズするとき  ファイルの状態を変更していなければ、別に回復 する必要もない  既に情報を読み出しているなら、あえて中断する 必要もない  ただし、記録はしよう  頻繁に発生していれば、問題を調査できる
  22. 22. 適用範囲  チェックされる例外  回復できるはず、回復が期待されている  回復しましょう  チェックされない例外  回復できなければ、せめて外側に伝播させて、速 やかに失敗させる  問題の発生箇所と発見箇所は近ければ近いほどよいの 法則

×