実施日時：2019/5/30　22:00～23:00
対象範囲：項目69～項目73
参加者：yodai、yoridori、kassyi
形式：オンライン(discord)
　　　課題本を事前に読み、実業務と照らし合わせて記述内容の
　　　議論をする。

項目69 例外的状態にだけ例外を使う
制御フローに対して例外を使うべきでない
ifの代わりに使われる例があるがやっていはいけない
異常な状態なのか普通なのか分からないので良くない
IntegerのparseIntで例外処理を使う事が有った

項目70 回復可能な状態にはチェックされる例外を、プログラミングエラーには実行時例外を使う
呼び出し元が適切に回復出来る様な状況ではチェックされる例外を使う
実行時例外ではIllegalArgumentExceptionなどを投げる
実業務での例外処理は、最終的にログに記録して画面に簡単なエラーメッセージを出すようにする。
画面入力の結果の例外は内容をメッセージとして画面に出す。

項目71 チェックされる例外を不必要に使うのを避ける
チェックされる例外を不必要に使うと、使う側は大変なことになる。
複数の例外が発生する場合は使う側が大変なので、まとめてApplicationExceptionを作成して、まとめて投げる。
引数を忘れるとどんなエラーか不明になるので、出来れば引数無しはprivateにすると良い
throw new ApplicationException(e)
ではなくて、
throw new ApplicationException()
とすると、eの情報が消えてしまいます。
297ページでもexceptionと使ったものとオプショナル使った例がある
オプショナルを使うとtryがifになる

項目72 標準的な例外を使う
パラメータが異常の場合は、falseを返すことが多い
エラーコードを返す場合は、IllegalArgumentExceptionを投げる事がある。
呼出元でエラーの処理がちゃんとしていた場合、例外を返した方がより綺麗に処理がまとまる。
true,falseでのパラメータ処理でなく、例外処理の場合はエラーコードやメッセージを入れて処理が出来る
true,falseでやるか例外でやるかはメンバーで意思統一をする必要がある
JavaDockで明記やドキュメントに記載する必要がある。

項目73 抽象概念に適した例外をスローする
P302、getのメソッドの中で、エレメントの存在エラーを値設定範囲外とのエラーに変換している。
SQL例外は出た所でエラーメッセージを投げて、例外をスローしないと調査が大変になる。
詳しいエラーは一番深い階層で書く

協力：Tech Baton
https://tech-baton.studio.design/