12月19日（月）1、2コマ目

今日、やったこと

Javaでの例外

今日のホワイトボード

Javaには例外が２種類ある

Javaには検査例外と実行時例外の２種類がある。ちなみに、C#の例外はJavaの実行時例外と同じ。

図　検査例外と実行時例外

検査例外をスローするメソッドは　throws句で例外スローを宣言する必要がある。

検査例外をスローするメソッドを呼び出す際は、例外をキャッチするか、キャッチしないならthrows句で例外スローを宣言する必要がある。


例外の使い分け

検査例外は必ずどこかでキャッチする必要がある。（キャッチしないとコンパイルエラー）

そのため、エラー処理を強制することができる。よって、利用者にリカバリ処理をしてほしいエラーは検査例外スローで通知すれば、どこかで必ずエラー処理をすることになる。

図　検査例外と実行時例外の使い分け


サンプルアプリケーション

ユーザー登録を行うアプリを作りました。

ポイントは

  • 利用者にリカバリしてほしいエラーはなに？
  • そんなエラー発生時にスローする検査例外をどうする？

です。

図　エラー発生時の対応


Userクラス(User.java)

とくになにもないかと。


UserDAOクラス(UserDAO.java)

insert()メソッドがポイント。

SQL実行時にエラーが発生すると、SQLExceptionがスローされる。

そのSQLExceptionにはgetErrorCode()メソッドがあり、戻り値がオラクルのエラーコード。

そのエラーコードで何が起きたかがわかるため、対応する検査例外をスローしている。


検査例外クラス(DupplicateIDException.java)

登録時に指定されたIDがすでに利用されているときにスローされる検査例外クラス。


検査例外クラス(InvalidInvitorException.java)

登録時に指定されたIDと紹介者IDが同じときにスローされる検査例外クラス。


検査例外クラス(NoInvitorException.java)

登録時に指定された紹介者が未登録のときにスローされる検査例外クラス。


サーブレット(IndexSrv.java)

ポイントはdoPost()。検査例外がスローされる=>利用者にリカバリを要請するです。


index.jsp

特になんてことはないかと。


次回は

評価用課題をやってもらいます。これがこの授業の最後の課題です。




このブログの人気の投稿

11月14日（月）1、2コマ目

イメージ
今日、やったこと 例外（C#) 今日のホワイトボード 処理終了時の状態 処理終了時は 正常終了 異常終了 の２つに分かれます。 さらに、異常終了も 想定内のエラー 想定外のエラー の２つに分かれます。 エラーを「想定内」、「想定外」 分けていますが、「想定外」なエラーもよく考えれば「想定内」なエラーになります。 ここで、エラーの内容を以下のように再定義します。 「想定 内 のエラー」は 利用者にエラー発生を伝えて、リカバリをしてほしい エラー。 「想定 外 のエラー」は 利用者に通知してもしょうがない エラー。 図　想定内のエラー、想定外のエラー 処理結果をどうやって伝える 処理(メソッド)の結果は 〇ユーザーに通知してリカバリしてほしいエラー 　 戻り値で通知 〇ユーザーに伝えてもしょうがないエラー 　 例外スローで通知 図　結果を伝える方法 ただし、 この方針は絶対的なものではありません 。 しかし、この授業では今後この方針でいきます。 戻り値は 結果が 成功 失敗 の2種類ならbool型へ。 処理結果の状態が3つ以上なら列挙型(enum型)で。 図　戻り値のつかいわけ 例外スロー時の対応 やってはいけない ことは 　 例外をキャッチしてもなにもしない(catchブロック内が空) です。 基本的に、例外がスローされたら そこで処理は中断 呼び出し元へエラー発生を通知（例外スロー） ...
続きを読む

10月27日（木）3、4コマ目

今日、やったこと [練習問題]C#＋コミット・ロールバック  今日のソースコード 正解例をあげておきます。 Startup.cs セッションなし。いつもどおり。 Item.cs プロパティ＋コンストラクタのクラス。いつもどおり。 ItemDAO.cs Update()メソッドがポイントでしょうか。 Index.cshtml.cs OnPost()メソッドがポイントでしょうか。 基本的な流れは以前Javaでやった同じ仕様の練習問題と同じです。 Index.cshtml とくにややこしいことはないかと思います。 次回は 今日の練習問題の解説とロックの練習問題です。
続きを読む

10月4日（火）1、2コマ目

イメージ
今日、やったこと トランザクション 今日のホワイトボード トランザクションとは 1件の処理＝１トランザクション。 たとえば、送金処理とか在庫更新とかで１つのトランザクション。 １つのトランザクションには複数のSQLを実行するケースが多い。 トランザクションに必要な要件 ACID特性が必要。 Atomicity（原子性） Consistency（一貫性） Isolation（独立性） Durability（永続性） トランザクションの原子性 トランザクション終了時には 全ての更新を実行 まったく更新をしていない のいずれかでなければならない。成功した更新と失敗した更新が存在するのはNG。 図　トランザクション終了時の状態 トランザクションの原子性はコミット、ロールバックで実現。 図　コミット、ロールバック トランザクションの独立性 トランザクションは単独で実行しても、複数同時に実行しても結果は同じでなければならない。 図　複数トランザクションが同時に実行されると そのために、トランザクション同士を分離、独立させて実行し、互いに影響が及ばないようにする。 このトランザクションの分離レベルが全く分離しない（Read Uncommitted)からほぼ完ぺきに分離する（Serializable）まで4段階ある。 この分離レベルに応じて、他トランザクションにいろいろな影響（ダーティーリード、ファジーリード、ファントムリード）が発生する。 ダーティーリード 他トランザクションで、更新したがコミットしていないデータを参照してしまうこと。 図　ダーティーリード 多くのDBの分離レベルはRead Committedなので、ダーティーリードは発生しない。 Read Committedなら、非コミットデータは参照しない。 ファジーリード 同じデータを参照しても、他トランザクションが更新することで、毎回異なるデータを参照すること。 分離レベルがRead Committedなら、コミットしたデータは参照できるため、ファジーリードが発生する。 ファントムリード 他トランザクションが追加、削除することで、参照するたびに出力行数が異なること。 分離レベルがRead Committedなら、コミットしたデータは参照できるため、ファントムリードが発生する。 ロック DB更新時には更新対象行をロックして、...
続きを読む