So-net無料ブログ作成

【Java】 例外は難しい ⑤

さて、長い間が空いてしまって結局何書きたかったのかすっかり忘れてしまった訳ですが。。。

結局、例外はどうさばけば良いか?という話ですが(強引に戻したっ)
「例外は極力書かない、書かさない」
これな。

まぁその名の如く例外というはやはり例外的な処理な訳ですから、
やたらめったら書くような機会があるのは多分設計が良くない…という話に落ち着くのではないかと。
だからといって使うのに萎縮してしまうのも、それはそれで違う訳なので勘違いされたくはないのですが。


■例外を使わざるを得ないポイント

① APIが検査例外をthrowする場合。
まぁ良くあるのはIO例外とSQL例外ですな。Web系なら…うーん忘れた(笑)
最近はバッチマンですからな!ハハハ。
(IO例外とSQL例外については別途記事を上げるかもしれない。)

キャッチしたらリトライするってのも一つの考えですが、まぁそんな面倒なことしたくないですわな。(酷い)
なもんでバッチ系ならどうせ終わらせるしかないのでError、
Web系ならキャッチしてエラーページ出す場合が多いでしょうから例外サブクラスに包んでポイすれば良いかと。
(ちゃんと専用の例外クラスを作ると尚良いね)

あぁでもFileNotFoundExceptionはthrow(s)しても良いね。
これはデフォルト設定なんかがある場合は対処しようがある。


② 成功・失敗を知らせる必要があるが戻り値をそれに使えない場合。
例えば良く例に出るログイン処理なんかの場合。
DBにユーザ情報が無かったFailed(※)とDBがぶっ壊れてそもそも問い合わせ出来なかったFailedは
明確に区別したい訳で。
片や再入力を促し、片やエラーページへ、みたいな。
そういうのは戻り値をbool値にしても判断できないし、数値(エラーコード)で返すって手も有るけど、
処理上、ログインチェックの戻りがユーザ情報だったりする場合は困っちゃいますね。
そういうときはやはり専用の例外を吐くとスッキリしたコードに出来そうです。

※ DBにユーザ情報が無かったFailedはそもそも正常処理(終了)であるので
  ユーザ情報有りの正常終了と判断がつかない…と言うべきかもしれない。

戻り値がプリミティブな場合も同じことが言えますね。
Integer.parseIntのNumberFormatExceptionの例がそのまんまですが、
これでエラーなら-1を返すとかやってしまうと変換された正しい-1なのか何なのか?と。

とは言え、これは使う側との約束(※)がしっかりしていれば発生しない場合もあるので、
極力そのお約束を文書化するなりして無くす方向に持って行きたいですね。
parseIntに数値を表す文字以外は渡すなよ…と。
(やはりチェックメソッド欲しいよなぁ。。。)

※ 例えばparseInt(に近い処理)の場合は変な数値は0に丸めますよ…と言ったルールを明文化できれば
  RuntimeExceptionを吐く必要すらない筈です。
  (公に使うAPIでそんな丸めが許される訳はないのでInteger.parseIntはRuntimeExceptionで正しい)


③ その他
なんかあるかもしれない。
まぁ予防線だ。ハハハ。
コメント(0) 
共通テーマ:資格・学び

コメント 0

コメントを書く

お名前:
URL:
コメント:
画像認証:
下の画像に表示されている文字を入力してください。

この広告は前回の更新から一定期間経過したブログに表示されています。更新すると自動で解除されます。