Javaの例外処理

例外処理について、漠然と進めてしまうと後で問題を特定するのが難しくなるので、開発チームのメンバーと意識を合わせて進めたほうが良いかと思う。というわけで、私の経験に基づいて、独断と偏見があるとは思うけど、思うことを以下にまとめておく。

  • 投げる例外は基本的に独自に作ったものを投げる。Exceptionとか、NullPointerExceptionとか、newして投げない。独自に作った例外のほうがログを見たときに自分のシステムのエラーなのかがわかりやすいと思う。
  • Seasar2とか、DI系のシステムだと独自に作った例外はRuntimeExceptionから継承しておく。メソッドにthrowsでいろいろと指定されていても変な依存になるし、面倒な気がするから。
  • Android系とかではExceptionを継承したほうが良いと思う。Androidの場合は、catchしないような例外はアプリを落とすことになるので、明示的な例外処理の方がリスクが低くなると思う。
  • 例外のログはthrowするところでなく、catchして例外を最終的に処理するところで書きだす。なので、必要な情報はthrowする例外にできるだけ保持させるのが良い。
  • 例外をこれからthrowしようとするところではERRORやWARNのログを吐かない。DEBUGやINFOであればよいが、ERRORやWARNをあちこちで書き出すと、ログファイルで追いにくくなる。
  • catchして、別な例外をthrowする場合は、Root Causeを忘れずに指定する。
  • Throwableはcatchしないほうが良い。Throwableの場合、その後の処理が継続できるかわからないし、Sonarに怒られるからやめたほうが良いと思う。
  • catchして例外を無視する場合、確実に無視して良いような例外以外はcatchしたときにログを書きだしておく。つまり、絶対にいらないと自信を持って言えなければログしておく。

まぁ、例外事項はあるかもしれないけど、あとはケースバイケースで…。

Archivaのパスワードポリシー変更

Archivaを導入して3ヶ月くらい経つとパスワードの再設定を要求される。これはこれで良いことだとは思うのだけど、運用する手間が増えるのでちょっと微妙…。というわけで、設定の変え方だけど、ここに書いてある。~/.m2/secruity.propertiesファイルを作成して、

# Security Policies
security.policy.password.previous.count=6
security.policy.password.expiration.days=90
security.policy.password.expiration.enabled=true
security.policy.allowed.login.attempt=3
# Password Rules
security.policy.password.rule.alphanumeric.enabled=false
security.policy.password.rule.alphacount.enabled=true
security.policy.password.rule.alphacount.minimum=1
security.policy.password.rule.characterlength.enabled=true
security.policy.password.rule.characterlength.minimum=1
security.policy.password.rule.characterlength.maximum=8
security.policy.password.rule.musthave.enabled=true
security.policy.password.rule.numericalcount.enabled=true
security.policy.password.rule.numericalcount.minimum=1
security.policy.password.rule.reuse.enabled=true
security.policy.password.rule.nowhitespace.enabled=true

を適当に編集しておいておく。security.policy.password.expiration.daysとかを適当に変更すれば良いかと。conf/security.propertiesの方は何か動かなかったけど、詳しく調べていない。